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GLOSSARY 



active foreground program: a foreground program is active 
if it is resident in memory, connected to interrupts, or 
in the process of being entered into the system via a 
!XEQ control command- 
area: a contiguous portion of a random access device that 
contains files of some related nature. 

background area; that area of core storage allocated to 
batch processing. This area may be checkpointed for 
use by foreground programs. 



oacKgrouna prog rani: 



KAnnlt-rsr 



control in the background area when no interrupts are 
active. These programs are entered through the batch 
processing input stream. 

batch processing: a computing technique in which similar 
programs are grouped together and processed or exe- 
cuted in a single run so as to effect efficient utiliza- 
tion of the computer. 

channel status table; a table of eight words per SYSGEN- 
defined I/O channel that reflects the hardware condi- 
tion of each I/O channel. 

checkpointed job; a partially processed background job 
that has been saved in secondary storage along with 
all registers and other "environment" so that the job 
can be restarted at its interrupted point. 

clock counter: a memory location that records the progress 
of real time or its approximation, by accumulating 
counts produced by a (clock) count pulse interrupt. 

close: terminating the use of an item (such as a file) and 
performing certain clean up operations to provide for 
its future reuse or the reuse of its resources. 

control command: any control message other than a key-in. 
A control command may be input via any device to 
which the system command input function has been 
assigned (normally a card reader). 

control message: any message received by the Monitor that 
is either a control command or a control key-in. 

count zero interrupt: an interrupt level that is triggered 
when an associated (clock) count pulse interrupt has 
produced a zero result in a clock counter. 



device-file number: a logical method of referring both to 
a physical peripheral device and to a collection of in- 
formation about the device. The device file number 
indicates the order in which devices are initially de- 
fined at SYSGEN. For example, the first device de- 
fined must always be a keyboard printer (DFN 1). 

device name: an identifier used at SYSGEN time for an 
actual physical I/O device that is composed of two 
elements: a device type which is a two-character code 
for a particular class of peripheral devices, and a de- 
vice number which is a two-digit hexadecimal repre- 
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a device 
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device unit number: an integer value coded into a 

FORTRAN IV program to reference peripheral devices. 
Standard device unit numbers can be equated to device 
file numbers (see above) either at SYSGEN time or 
through [ASSIGN commands. 

directory: a table of names and addresses of files on a ran- 
dom access device that enables the system to locate. a 
file when given only its name and area. 

disabled: the condition of an interrupt level wherein the 
level may advance from the armed to the waiting state 
when triggered by an interrupt pulse, but the level 
cannot cause a program interruption until it is enabled; 
it thus remains in the waiting state until it is allowed 
to interrupt the program. 

disarmed state; the state of an interrupt level that cannot 
accept an interrupt input signal. 

disk pack: a secondary storage system of removable rotating 
memory. For most RBM purposes, disk pack and RAD 
are synonymous unless otherwise noted. 

enabled: the condition of an interrupt level wherein 
the level is not inhibited from advancing from the 
waiting state to the active state except for priority 
considerations. 

end action: that action that takes place at the completion 
of an I/O operation. This usually includes the entry 
of a special routine that was specified when the re- 
quest was made. 

end record: the last record to be loaded in an object 
module or load module. 



critical task: a task whose importance is high enough that 
no attempt should be made to run without it in the 
event of a serious error. 

dedicated memory: core memory locations reserved by the 
Monitor for special purposes, such as interrupts and 
real-time programs. 



error severity level code: a code indicating the severity 
of error noted by the processor. This code is con- 
tained in the final byte of an object module. 

execution location: a value replacing the origin of a 
relocatable program that changes the address at which 
program loading is to begin. 



external interrupt: one of the class of interrupts that are 
associated with special systems equipment. These 
interrupts are "external" to the basic computer sys- 
tem and are associated with functions that are de- 
fined according to the requirements of a particular 
installation. 



external interrupt inhibit: the bit, in the program status 
doubleword, that indicates whether (if 1) or not (if 0) 
all external interrupts are inhibited. 

external reference: a reference to a declared symbolic 

name that is not defined within the module in which 
the reference occurs. An external reference can be 
satisfied only if the referenced name is defined by an 
external load item in another module. 

file control table: contains information about all device 
files in the RBM system and is indexed by device-file 
number. 

file name: a name for a permanent file that is defined 
either at SYSGEN or later through the RAD Editor. 



installation control command: any control command used 
during System Generation to direct the formatting of 
a Monitor system. 

internal interrupt: one of the calss of interrupts that are 
supplied with a standard computer system, or are op- 
tional additions associated with dedicated functions 
(such as power fail-safe). These interrupts are 
"internal" to the basic computer system. 

interrupt trigger signal: a signal that is generated, either 
internal or external to the CPU, to interrupt the nor- 
man sequence of events in the central processor. 

I/O block: a contiguous amount of RAD or disk space that 
contains records of blocked or compressed files. All 
I/O blocks are the same size (K:BLOCK) and always 
begin on a sector boundary. K:BLOCK also specifies 
the size of core blocking buffers. 

I/O control table: a table containing the device-specified 
input/output control doublewords and other information 
necessary for RBM I/O services. There is a one-to-one 
correspondence between the I/O control table and file 
control table. 



flawed track: a disk pack track that contains a flaw mark 
in the header as well as the address of an alternate 
track. 

foreground area: that portion of memory dedicated speci- 
ficially for RBM, service routines, and foreground 
programs. 

foreground program: a program that executes in the fore- 
ground area of core and can utilize all privileged 
services. 

foreground task: a body of procedural code that is associ- 
ated with (connected to) a particular interrupt. 

GO file: a RAD file of Relocatable Object Modules 

(ROMs) formed by a processor. This is a default input 
file when no file name is specified. 

granule: a record beginning on a physical sector boundary, 
used as a unit of allocation for random RAD or disk 
pack files. A granule is usually synonymous with a 
sector on a device, but may be defined (on a file basis) 
to be equivalent to a partial sector, one sector, or 
several sectors. 

idle state: the state of the Monitor when it is first loaded 
into core memory or after encountering a !FIN control 
command. The idle state is ended by means of an 
S key-in. 

inhibited interrupt: a condition of an interrupt that pro- 
hibits it from entering the active state. 

input/output interrupt: an interrupt triggered by the stan- 
dard I/O system of the computer. 



I/O control subtable: same as I/O control table except 
that the subtable is RAD specific. 

library input: input from the device to which the LI (library 
input) operational label is assigned. 

library load module: a load module that may be combined 
(by the Overlay Loader) with relocatable object mod- 
ules, or other library load modules, to form a new ex- 
ecutable load module. 

link editing: the process of combining separately compiled 
or assembled program modules, relocating them, link- 
ing them to defined library routines, and producing an 
absolute executable load module. 

loading: the process of reading an executable program (see 
link editing above) from secondary memory to absolute 
locations in main memory. 

load map: a listing of significant information pertaining to 
the storage locations used by a program. 

load module: an executable program formed by using Re- 
locatable Object Modules and/or library object mod- 
ules as source information. 

logical device: a peripheral device that is represented in 
a program by an operational label (e.g. , BI or BO) 
rather than by a specific physical device name. 

logical record: a record that is a fixed measure of contig- 
guous data (on a file basis), distinctive as being mean- 
ingful to the user. For blocked RAD files, logical 
records are contiguous within blocks but need not be 
integral to a block. 



memory protection: the use of the optional protection fea- 
ture that keeps unprotected background memory from 
altering protected foreground meaning. 

memory write lock: a one-bit write-protect field optionally 
provided for each 256-word page of core memory 
addresses. 

Monitor: a program that supervises the processing, loading, 
and execution of other programs. 

nonresident foreground program: a foreground program 

explicitly called from secondary memory that resides in 
the nonresident foreground area of core memory during 
execution. The space thus occupied is considered 
"active" and is protected by the Monitor from inter- 
ference by other activities. 

object deck: a card deck comprising one or more object 
modules and control commands. 

object language: the standard binary language in which 
the output of a compiler or assembler is expressed. 

object module: the series of records containing the load 
information pertaining to a single program or sub- 
program. Object modules serve as input to the 
Overlay Loader. 

open: the preparing of an item (such as a file) for initial 



operational label: a symbolic name used to identify a logi- 
cal system device. 

operational label table: there are two tables: one for fore- 
ground and one for background. The tables contain 
the two-character operational labels that are used for 
reference by the RBM service routines and connect an 
operational label to a device file number. 



postmortem dump: an optional listing of the contents of a 
specified area of core memory, usually following the 
abortive execution of a background program. 

primary reference: an external reference that must be 
satisifed by a corresponding external definition (capa- 
ble of causing loading from the System Library). 

priority level: priority level of a task is dependent on the 
position of its associated hardware interrupt in the 
priority chain. 

RAD/disk areas: the allocation and definition of a RAD 
into specific areas during SYSGEN, each of which is 
labeled with a two-character mnemonic to expendite 



Rapid Access Data (RAD) storage system: a secondary stor- 
age system of rotating memory. For most RBM pur- 
poses, RAD and disk pack are synonymous unless other- 
wise noted. 



real-time processing: data processing designed so that the 
results of the operations are made available in time to 
influence some process being monitored or controlled 
by the computer system. 

reentrant: that property of a program or subroutine that 
enables it to be interrupted at any point, employed by 
another user, and then resumed from the point of in- 
terruption. Reentrant programs are often found where 
there is a requirement for a common store of public 
routines that can be called by any user at any time. 
The process is controlled by the Monitor which preserves 
the routine's environment (registers, working storage, 
control indicators, etc.) when it is interrupted and 
restores that enviomment when the routine is resumed 
for its initial user. A reentrant routine never stores 
any intermediate values within itself. 



option: an elective operand in a control command or pro- 
cedure call. 

Overlay Loader: a processor that links and absolutizes 
elements of programs. 

overlay program: a segmented program in which the seg- 
ment currently being executed may overlay the core 
storage area occupied by a previously executed 
segment. 

OV file: a RAD file that contains an executable program 
formed by the Overlay Loader if a program file name 
was not specified at load time. Used primarily to test 
new programs or new versions of programs. This is a 
default file when no output file is specified. 



Relocatable Object Module: a program or subprogram that 
may be relocated and link edited to operate anywhere 
in core; that is, does not have absolue addressing. 

resident foreground program: a foreground program that is 
automatically loaded into a fixed area of foreground 
core memory every time the system is booted in. 



or 



secondary reference: an external reference that may 
may not be satisfied by a corresponding externa, 
definition (not capable of causing loading from the 
system library). 



secondary storage: any rapid access storage medium other 
than core memory (e.g. , RAD or disk pack). 



physical device: a peripheral device that is referred to by 
a "name" specifying the device type, I/O channel, 
and device number (also see "logical device"). 



segment loader: a Monitor routine that loads overlay seg- 
ments from RAD storage at execution time. 



semi resident foreground program: a foreground program 
explicitly called from secondary memory that resides 
in the resident portion of core memory during 
execution. 

service routines: Monitor-supplied services and opera- 
tions that can be called by an executing foreground 
program, or else by an executing background program 
(except for certain privileged function dedicated to 
foreground use). 

source deck: a card deck comprising a complete program 
or subprogram in symbolic EBCDIC format. 

source language: a language used to prepare a source 
program (and therefrom a source deck) suitable for 
processing by an assembler or compiler. 

symbolic input: input from the device to which the SI 
(symbolic input) operational label is assigned. 

symbolic name: an identifier that is associated with some 
particular source program statement or item so that 



symbolic references may be made to it even though 
its value may be subject to redefinition. 

system library: a group of standard routines in relocatable 
object language format, any of which may be included 
in a program being created. 

Task Control Block (TCB): part of the load module that 
contains the area required for context storage. The 
TCB is task-associated. 

temporary files: those files that exist only until the current 
job step ends. They may, or may not, have existed 
prior to the start of the job. 

Temp Stack: an area of memory optionally created by 
the Overlay Loader for a user program and used by the 
Monitor and System Library routines. 

unsolicited key-in: information entered by the operator via 
a keyboard in response to a Control Panel interrupt. 



1. INTRODUCTION 



RBM CHARACTERISTICS 

The Sigma 2/3 Real-Time Batch Monitor (RBM) is the major 
control element in the operating system. It supervises and 
services simultaneous foreground programs and background 
batch programs without interfering with the real-time re- 
sponse capability of the foreground. 



RESIDENT SECTION 

The resident portion of RBM consists of the following parts: 

• Several independent tasks that are connected to the 
hardware interrupts (e.g., the real-time tasks). The 
tasks are not reentrant. They can communicate with 
each other and may use some of the Monitor service 
routines. 

• Several reentrant Monitor service routines that can be 
used by any task in the system. These are described 
in Chapter 4. 

• Standard system constants and tables (see Appendix B). 

• Input/output constants and status information. 



NONRESIDENT SECTION 

The nonresident part of RBM consists of the system initiali- 
zation portion that is loaded at the time the system is cre- 
ated, Monitor service routines, and device-dependent I/O 
routines for which a response is not critical. The initiali- 
zation portion selects the optional features of RBM and 
initializes the input/output constants. 



SYSTEM ENVIRONMENT 

In addition to the Monitor itself, the hardware-software 
environment of the operating system consists of the following 
major elements: 

• Sigma 2/3 hardware including (a) the required system 
RAD, (b) the selected number of hardware interrupts 
connected to various foreground tasks in user-determined 
priority sequence, (c) dedicated and commonly shared 
I/O devices, and (d) optional secondary storage modules. 

• Partitioned core memory (see Figure 1) divided into 

o A protected foreground area reserved for (1) resi- 
dent real-time foreground programs, (2) a single 
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nonresident foreground program, (3) Monitor tasks 
that must respond to high-priority interrupts, 
(4) Monitor service routines, and (5) optional 
routines (such as a Public Library) that are used 
by both foreground and background programs. 

o An unprotected background area used by back- 
ground (non-real-time) processors, translators, and 
batch users' programs, and occasionally by fore- 
ground programs requiring temporary use of addi- 
tional memory. (In this case the foreground will 
checkpoint the background.) 

The system RAD, allocatable into permanent and tem- 
porary files. The permanent files contain all of the 
background RBM processors such as Basic FORTRAN IV, 
Extended Symbol, RAD Editor, etc., plus RBM itself. 
They may also contain user data and optional resident 
and nonresident foreground programs that can be called 
into protected memory for processing. Temporary files 
are normally used as intermediate scratch areas by 
processors or user programs. 

Up to 137 (107 for Sigma 3) user foreground tasks that 
can be connected to interrupts. Examples of foreground 
tasks are process control operations, real-time data ac- 
quisition and control, and low-speed telemetry applica- 
tions. The RBM Control Task is connected to the lowest 
priority hardware interrupt in the system so that no 
background processing can delay foreground tasks. 

Overlay Loader for linking and absolutizing segmented 
foreground and background programs that enables back- 
ground processors and user programs to overlay them- 
selves in core storage, and thus permitting programs of 
virtually unlimited size to be executed. 



FOREGROUND (High-Level Priority Response) 

Within the framework of the user-determined hardware 
interrupt priorities, foreground programs or tasks operate as 
independent entities, and the Monitor generally makes no 
attempt to interject itself between these tasks and their real- 
time functions. The Monitor services the foreground only 
on request, such as a call to one of the Monitor service rou- 
tines. The principal foreground services of the Monitor are to 

• Respond to I/O interrupts. 

• Respond to an operator's console request (such as 
queuing). 

• Supervise RAD file activity. 

• Optionally, supply a software version of multiply/ 
divide functions for configurations without multiply/ 
divide hardware. 



• Load a foreground program into memory from the RAD 
on request. 

• Provide the foreground with standard constants (see 
Appendix B). 

• Make available a "mailbox" area of 32 cells of mem- 
ory for communication between two or more foreground 
programs. 

The interrupt priority sequence (described in detail in the 
Xerox Sigma 2 and Sigma 3 Computer Reference Manuals) is 
the basis for the priority level of tasks in the RBM system. 
That is, the priority level of a task is dependent on the 
position of the associated hardware interrupt in the inter- 
rupt priority chain. Background jobs in the system all have 
the same priority level. A background job is not connected 
to any interrupt level in the system, i.e. , its priority is be- 
low all hardware interrupt levels and is processed serially. 



BACKGROUND (Low-Level. No Priority) 

The primary function of the Monitor is to supervise and con- 
trol all those operations that take place in the unprotected 
background area by the following means: 

1. Use only available foreground idle time for back- 
ground processing. 

2. Interpret control functions from control command card 
images via the Job Control Processor. 

3. Supervise the loading and execution of all back- 
ground jobs and activities in unprotected memory. 

4. Provide simple background scheduling (first-in, 
first-out). 

5. Provide I/O services for the background job stack. 

6. Inform the operator on the status of peripheral device 
operations. 

7. Test all background operations and processes for fore- 
ground protection violations and prevent the background 
from altering or delaying foreground response or from 
using dedicated I/O devices. 



Monitor processors and permanent user processors may be 
loaded onto permanent RAD files and then executed by 
control command. Programs may also be loaded onto tem- 
porary RAD files for the duration of the present job. 



For RBM purposes, RAD and disk pack are synonymous 
unless specifically stated otherwise. 



All programs must exist on the RAD in absolute core image 
form for execution. Relocatable programs, consisting of 
a root and one or more overlay segments linked by ex- 
ternal references, must be created by the Overlay Loader 
to link all modules and create the proper overlay struc- 
ture for execution. 
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It is possible to create programs consisting of a root and one 
or more overlay segments through use of the Absolute Loader 
if there are no external references (see the !ABS command in 
Chapter 2 for other restrictions). 

Two levels of logical (rather than physical) device refer- 
encing are provided, enabling system configurations to 
change or expand without reprogramming. Further, through 
many device-independent features and use of standard media 
formats, input and output can be directed to card equipment, 
paper tape equipment, or magnetic tape without changes in 
the user's program. 

For maximum flexibility and control of input/output, the 
user can optionally specify his own I/O Control Double- 
words and order bytes, perform independent error recovery, 
and be informed by RBM when an I/O operation has term- 
inated. Alternatively, for greater ease of programming and 
device independence, the RBM will create the IOCDs and 
order bytes and perform standard error checking and recovery. 

When multiprogramming with foreground tasks and back- 
ground jobs, the foreground has access to all privileged in- 
structions in the Sigma 2/3 computers. The background is 
checked by both hardware and software to provide complete 
protection of a foreground program's use of core memory and 
peripheral operations. 



SECONDARY STORAGE MANAGEMENT 

The RBM operating system provides use of the RAD or disk 
packs for 

• Temporary and permanent files. 

• User and system files. 

• Sequential files (pseudo tape, where RBM performs all 
file management). 

• Random-access files (RBM performs I/O transfer and con- 
trols file limits, but user controls relative addressing). 

RAD/DISK PACK AREAS 

The concept of RAD areas is a convention created primarily 
to offer a scheme to expedite file management. RAD areas 
are allocated during system initialization (see RAD Alloca- 
tion in Chapter 11) and are labeled with two alphanumeric 
characters, usually from the following list: 



SP 



BT 



BP 



act 



SD CP UP Xn 



SL FP UL 



The labels of the list above have the special meaning given 
in Table 1 . 

Table 1 . RAD/Disk Areas 



Mnemonic 



SP 



SD 



SL ,UL 



UP,FP,BP 



BT 



CP 



where aa is any remaining combination of alphanumeric 
characters. 



aa 



Xn 



Meaning 



System Processor area. Contains RBM and 
user-selected processors from the list given 
in Table 5 (the Overlay Loader is a man- 
datory processor). This area is searched 
whenever either a system processor or user 
processor is requested. 

System Data area. Contains files neces- 
sary for the execution of RBM. 

System Library and User Library areas. 
These are the only areas from which the 
Overlay Loader will load library routines. 

User, foreground, background processor 
areas. Contains resident foreground pro- 
grams, foreground tasks, nonresident pro- 
grams, semi -resident programs, and back- 
ground programs. Area FP may only con- 
tain files of foreground or no-write pro- 
tect codes and area BP may only contain 
files of background or no- write protect 
codes. The UP area may have its area 
write protection specified during System 
Generation or RAD Editing. These areas 
and the SP area are searched when a pro- 
cessor is requested. Only UP is searched 
for resident foreground programs, when the 
system is booted from the RAD. 

Background Temp area. Used for alloca- 
tion of temporary files. 

Checkpoint area. Used to store the back- 
ground environment when a background 
program is checkpointed by a foreground 
process. 

User data areas which contain any data 
the user desires, including program files. 

Xn areas are similar to aa areas except 
that the user has the option to perform his 
own management of the entire area, thus 
allowing access to data arranged in non- 
standard formats. No disk pack verifica- 
tion is performed for an M (Mount) key- 
in (see "M Key-Ins" in Chapter 3). 



These areas receive defaultallocationsduring SYSGEN. 
Note that the SP and SD areas must be present in the 
system 
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PROCESSOR FILES 

Processor files are stored either as a single segment or as an 
overlay structure. The Overlay Loader stores the files on 
the RAD in core image form, ready for loading, and abso- 
lutized for the space they will occupy at execution. The 
processor files are loaded for execution via a processor con- 
trol command. 



LIBRARY FILES 

Library files contain subprograms in a relocatable form. 
The files have specified entry points and are in the form of 
binary card images in Standard Object Language. 

There is one Ubrary fiie for the system area mnemonic SL, 
and one for the user area mnemonic UL. The Overlay 
Loader can load selectively from one or both, in either 
order of priority. Although records within a subprogram 
are loaded sequentially, access to the individual subpro- 
gram is on a random (direct access) basis. 



routine M:SEGLD is used to control both the loading and 
the transfer of control between various segments. 



CHECKPOINT/RESTART 

The checkpointing feature permits a partially processed 
background job to be saved in secondary storage along with 
all registers and other environment. The vacated back- 
ground space is set to protected status and is then available 
to the interrupting foreground task for either instructions or 
temporary data storage. 

Checkpointing ensures continuity to the partially completed 
background job by not repositioning any background periph- 
eral devices, permitting all current background I/O activity 
to complete, and writing a!! of the background space onto a 
prespecified RAD area. 

Restart takes place when the previously checkpointed back- 
ground program is reloaded from the RAD and continues 
execution as though the interruption never took place. 



DATA FILES 

Permanent data files may contain any kind of data and may 
be accessed sequentially or randomly, depending on how 
they were created. The user is responsible for reading them 
accordingly. 



FILE NAME 

Only permanent RAD files have a file name. Some names 
are entered into the dictionary for the appropriate area at 
System Generation; others are entered later by the RAD 
Editor. After the name is in the dictionary, an ! ASSIGN 
control command or a call to M:ASSIGN can equate either 
an operational label or a FORTRAN device unit number to 
this file name. 



OVERLAY CAPABILITIES 

Under RBM, the Overlay Loader can be used to create over- 
lay programs for later execution in either the foreground or 
background. * The overlay programs can be permanently 
entered (as a file) into. either the System or User Processor 
areas, or into a temporary overlay file (OV). Since they 
are stored on the RAD in absolute core image format, they 
can be quickly loaded into memory for execution. 

Each segment is created by the Overlay Loader from one or 
more object modules (assembly language, FORTRAN, or 
library routines). The control commands required to create 
the overlay segments are defined in the discussion of the 
Overlay Loader. During execution, the Monitor service 



For a complete description of the Overlay Loader, see the 
Overlay Loader chapter. 



PUBLIC LIBRARY 

All RBM service routines and Sigma 2/3 system library rou- 
tines (FORTRAN and mathematics libraries) are reentrant. 
If an RBM system has several real-time foreground tasks that 
use a number of the same subroutines, the collectively-used 
set of subroutines can be loaded together into what is termed 
a Public Library. Thereafter, whenever the Overlay Loader 
processes a foreground or background program that references 
one of the "public" routines, it sets the appropriate branch 
to the Public Library. The Public Library is loaded into core 
whenever RBM is rebooted from the RAD. 

When one of the Public Library routines needs temporary 
scratch space, it requests space (via a call to M:RES) from 
the temporary stack of the task that is calling the Public 
Library routine. When the library routine exits, the space 
is released via a call to M:POP. 



REENTRANT ROUTINES 

As used in Sigma 2/3 software, "reentrant" means that a 
subprogram (never a task) may be interrupted during execu- 
tion, called again by the interrupting task, and later re- 
entered and continued from the location of the former task. 
This is a last-in, first-out kind of reentrancy in keeping 
with the Sigma 2/3 priority interrupt system. 



ACCOUNTING AND ELAPSED TIME 

Background job accounting and provisions to limit the exe- 
cution time of a background job can be accomplished via 
Clock 1. (The use of Clock 1, an interrupt device, is 
optional at SYSGEN initiation.) To correctly calculate 
the elapsed time for the background, the Monitor MrSAVE 
routine records the start time of the first interrupting fore- 
ground task and triggers the RBM Control Task to calculate 
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the actual foreground run time. By performing this calcu- 
lation at the priority level of the RBM Control Task, rapid 
response time for the foreground is maintained. 

Clock 1 is also used to limit the execution time of a back- 
ground program. The user may limit this execution time by 
using the ! LIMIT control command, and the RBM Control 
Task will be triggered every 16 seconds to provide watchdog 
services on the background program. 

When a !JOB control command is read, an entry is created 
in the accounting file (RBMAL, SD). The entry includes the 
start time, user name, and account number. The start time of 
the job is then logged on the LL device as MM/DD/YR HRMN. 

At the completion of each activity, the accumulated elapsed 
time of background execution will be logged on the LL 
device as ET=MMM.MM (minutes). At the completion of 
the job (i.e., a new !JOB or !FIN command) the current 
date and time and a job recap are logged on the LL device as 



MM/DD/YR HRMN 
FG-MMM.MM, 
where 



BK=MMM.MM, 
ID-MMM.MM 



BK represents the total job time. The total time 
for a job is defined as the time available to the 
background from the time the ! JOB control com- 
mand is read until the next ! JOB or ! FIN command 
is encountered. 

FG represents the amount of time used by inter- 
rupting foreground tasks during the job. 

ID represents the accumulated idle time incurred 

within the job. This could be a result of a Wkey-in, 
! PAUSE command, or an attended job being aborted. 



• The ET (elapsed time) is printed on each time CCI is 
read into the background and represents the total time 
available for background execution. 



SYSTEM INITIALIZATION AND CREATION 

The RBM system creates itself for a particular installation 
through a nonresident SYSGEN routine. The permanently 
resident, nonoptional parts of RBM are loaded into low core; 
next, the RBM initializer is loaded along with the optional 
RBM routines and the standard input/output definitions 
and tables. 

The user then defines RAD areas, optional reoutines, the 
peripheral devices, and operational labels. This is followed 
by a definition of the exact bounds on the foreground, 
Monitor, and background memory areas, and the size of the 
RAD areas. The system is then complete in lower memory. 

Once the system is completely defined, routines not needed 
will be discarded and an absolute rebootable version is 
optionally punched on a binary output device (optional) and 
a rebootable version is written onto the RAD. 

If the system must be restarted later, the rebootable version 
is loaded from the RAD. A completely new system initiali- 
zation is necessary only if some of these standard definitions 
must be changed. 

When the system is created, a version number is specified 
that will be printed on LL at the beginning of each job for 
reference. 

Protection switches on the 7202, 7203, 7204, and 7232 
equipment may be used to permanently protect certain areas 
of the RAD. 



The time for a background job is recorded in the accounting 
file entry for that job. The IDLE account is updated to re- 
flect total idle time charges. After the !FIN control com- 
mand is read, all idle time is charged to the IDLE account. 

The following rules govern the operations of the Accounting 
Log: 

• A call to M:SAVE switches from the background to 
foreground time accumulation. 

• A call to M:EXIT switches from foreground accumula- 
tion to background accumulation if a background job 
is executing. 

• AW key-in or ! PAUSE command switches from fore- 
ground accumulation to idle time accumulation. An 
abort from an attended job switches the same way. An 
S key-in switches back to foreground accumulation 
from the idle accumulation. 

• A !JOB or !FIN command writes out total accumulated 
times and resets times to zero. 



HARDWARE REQUIREMENTS 

The minimum configuration required and supported by RBM 
for either a Sigma 2 or Sigma 3 is the following: 

Sigma 2 or Sigma 3 CPU with either Internal IOP or 
External IOP (Sigma 3 only) 



Memory Parity Interrupt 

Memory Protect Feature 

Hardware Interrupt (for RBM Control Task) 

Core Memory Module (8192 words) 

One Memory Increment (8192 words) 

Keyboard/Printer with Paper Tape Reader/Punch 

RAD Controller 

RAD Storage Unit (0.75 M bytes). 
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An alternate minimum configuration (for a Sigma 3 CPU with 
external IOP only) is a Disk Pack Controller and Disk Pack 
Storage Unit to replace the RAD Controller and RAD storage 
Unit. Other minimum requirements remain the same. 

In addition to the previous list, any items from the list 
below can be added for increased performance and will be 
specifically supported by RBM. Other items can be added 
to this list but will not receive any special RBM support. 

Disk Packs 

Memory Module 

Memory Increment 

,w / uv - ,v "' — 

Paper Tape Recorder/Punch (high-Speed) 

Card Readers 

Card Punches 

RADs 

Magnetic Tape, 9-Track 

Magnetic Tape, 7-Track 

BCD and Binary Packing Options for 7-Track Magnetic 
Tape 

Line Printers 

Plotters 

Character Oriented Communications (COC) device. 

RBM SUBSYSTEMS 

RBM will support the subsystems and processors described 
below. All execute in the background area of core memory 
and the collective set offers maximized utilization of 
Sigma 2/3 computer capabilities. 

LANGUAGE TRANSLATORS 



EXTENDED SYMBOL 

The Extended Symbol programming language (and assembler) 
provides upward compatibility with basic Symbol in addi- 
tion to extended capabilities that include using the RAD 
for overlay to reduce core residence requirements. 

The processor accepts as input a source program coded in 
either Symbol or Extended Symbol, processes it, and out- 
puts an object program load module, diagnostic messages, 
an optional assembly listing, and an optional cross-refer- 
ence listing. 



BASIC FORTRAN IV 

Basic FORTRAN IV is a one-pass compiler with capabil- 
ities extended beyond Basic FORTRAN. It can compile 
large source programs by using the RAD for overlay to mini- 
mize core residence requirements, and has two floating- 
point modes: standard precision and extended precision. 



SERVICE PROGRAMS 

OVERLAY LOADER 

The Overlay Loader forms absolute binary overlay segments 
for later execution in either foreground or background area$. 
If a resident or nonresident oroaram can tolerate a loadina 
delay of 20 to 100 ms, foreground or background programs 
of virtually unlimited size can be constructed with the 
Overlay Loader despite limitations in available core storage. 

RAD EDITOR 

The RAD Editor performs RAD allocation for permanent files 
and generates and maintains directories for the permanent 
RAD areas: System Processor area, System Library area, 
System Data area, User Processor area, User Library area, 
User Data area, and any aa areas and Xn areas. It allows 
dumping of files and mapping of all RAD areas, including 
checkpoint and temporary areas. 

UTILITY SUBSYSTEM 

The RBM Utility subsystem provides a universal media copy 
routine, object module editor, dump routine, and record 
editing by line or sequence number. 

CONCORDANCE 

The Concordance program provides the user with a listing 
of program symbols and all references to these symbols by 
source line number. Optional control cards permit inclusion 
or exclusion of specified symbols in local, nonlocal, or 
operation/directive code sections of the printout. Most of 
the options of Concordance are available under Extended 
Symbol. 

Omission of optional control cards yields a standard Con- 
cordance listing containing all program symbols except 
standard operation and directive code menmonics. 
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DEBUG 



The RBM Debug subsystem provides the user with a debug- 
ging tool designed primarily for nonsegmented background 
programs but with a limited capability for debugging fore- 
ground programs. The Debug functions and commands are 
described in Chapter 12. 
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coc 



PROGRAM 



The character-oriented communications (COC) handler pro- 
vides communication between Sigma 2/3 real-time programs 
and various terminal devices. The COC consists of a con- 
troller and from one to eight attached line interface units. 
The Sigma 2/3 RBM can accommodate one COC. See 
Chapter 4 and Appendix F for a more complete discussion 
of the COC handler. 



RBM TERMS AND PROCESSES 

The following items are either unique to the RBM system or 
have specific meaning within the RBM context. Terms and 
processes not defined beloware explained in the appropriate 
chapter. 



TASK 

A "task" is an entire set of foreground operations performed 
independently of other tasks in the system. It must be con- 
nected to one and only one hardware interrupt. A task may 
use Monitor service routines but must never branch to another 
task. One task may trigger the interrupt level of another 
task by means of a Write Direct instruction. The prescribed 
entrance and exit procedure for all real-time tasks in the 
system is described in Chapter 6. 

A task logically consists of three parts (that may or may not 
be contiguous in core storage): 

1 . A Task Control Block (TCB) that contains status infor- 
mation and the contents of the registers from the inter- 
rupted task (see Table 17). The TCB is normally the 
first loadable item in the object module. 

2. A task body, consisting of a sequence of instructions 
executed in response to the task interrupt. 

3. A task temporary storage area for use by the Monitor 
service routines (and other reentrant library routines) 
to provide reentrancy for these routines. 

Examples of foreground tasks are 

• Real-time foreground tasks connected to external 
interrupts. 

• Monitor I/O interrupt routine. 

• Monitor Control Panel interrupt routine. 

• Monitor memory parity and protection violation 
routines. 

• RBM control routine (for loading, abort, etc.). 



A background program can also operate as a single task but 
without foreground privileges. 



A "program" is one or more tasks (and optionally, some 
command data storage) that are loaded and controlled as a 
unit. Four types of programs exist under RBM: 

1 . Resident foreground programs consisting of one or more 
tasks, perhaps some special routines for receiving I/O 
interrupt responses (see "End Action"), and any com- 
mon storage that may be needed. 

2. Semi resident foreground programs that are explicitly 
called in from secondary memory and reside in the 
resident portion of core memory during execution. 

3. Nonresident foreground programs. 

4. Background programs, consisting of a single task. 

FOREGROUND 

"Foreground" refers to real-time or Monitor tasks executed 
in protected memory on a real-time basis. Since the num- 
ber of foreground tasks is limited only by the number of 
internal and external interrupts possible in the system, the 
fundamental limitation is the amount of core space available. 
However, the use of overlays and nonresident foreground 
programs makes the amount of effective foreground space 
virtually unlimited, depending only on the severity level 
of required response times. 

BACKGROUND 

"Background" refers to a non-real-time program executed 
in available nonprotected memory. The purpose of back- 
ground programming is to achieve higher efficiency in the 
system by using up the available CPU time not needed by 
real-time tasks to maintain foreground programs, or to per- 
form other data processing functions. 



Background operations may be assemblies, compilations, 
data processing, or utility operations. The two fundamental 
restrictions in using background programming are 

1. Sigma 2/3 hardware and the RBM software completely 
and absolutely protect resident foreground programs 
from a background program in terms of I/O and core 
memory usage. Thus, a background program is never 
allowed to interfere with real-time foreground tasks: 
it must operate in nonprotected memory and use the 
Monitor service routines for all I/O or other privileged 
operations. 

2. Since a background program uses only the CPU time 
available after the real-time foreground is satisfied, it 
may not be guaranteed any CPU time when foreground 
is very active. The background is not allowed to 
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Inhibit Interrupts or do anything else that might inter- 
fere with real-time foreground responsiveness. 



JOB 



A "job" is defined as consisting of all background activities 
or processes that take place between a ! JOB command and 
the next ! JOB command or a !FIN command (whichever is 
encountered first). 



JOB STEP 

A "job step" is defined as the operations performed in setting 
up and processing a single program within a job stack. A 
job step is initiated by calling in a background processor 
and ends when the processor exits. 



BACKGROUND TASK 

A "background task" is an executable version of a single 
background process that shares the same restrictions as 
other background jobs relative to foreground priorities 
and privileges. 



MONITOR SERVICE ROUTINES 

RBM service routines can be used by real-time foreground 
tasks, a background task, or RBM tasks. All routines are 
coded in a reentrant manner, and those that require tempo- 
rary storage use the temporary stack space associated with 
the task that calls the routine (see Chapter 4). 



The floating-point accumulator is assumed to occupy the 
first six locations of the temporary stack space. It is used 
like a hardware accumulator, i.e. , to build up a cumula- 
tive result from single-precision or double-precision real 
(floating-point) calculations. 

As a convenience in referencing the floating accumulator, 
core locations 1 through 5 are set with pointers to the actual 
core locations. This is done when entry is made to the ac- 
tive task (byM:SAVE when the routine is used). Therefore, 
indirect addressing through locations 1 through 5 will result 
in storing, loading, or modifying the actual floating accu- 
mulator. The sixth cell of the floating accumulator is used 
by the FORTRAN-formatted I/O routine. 

RBM CONTROL TASK 

The RBM Control Task encompasses a number of subtasks 
that control the reading of control commands, loading back- 
ground programs, interpreting unsolicited key-ins, and 
aborting or terminating a background job. During system 
initialization, the RBM Control Task must be assigned to the 
lowest priority hardware interrupt. 

The RBM Control Task uses the same entrance and exit pro- 
cedure and the same type of TCB as a real-time foreground 
task. Since its main function is to control background 
activity, it has a lower priority than any real-time task. 
It is necessary that this be a separate task (and not part of 
the background priority level) so that effective and respon- 
sive control can be made through key-ins. All RBM func- 
tions associated with this level operate as subtasks to the 
RBM Control Task and are non-reentrant. 



NONRESIDENT FOREGROUND 



TEMPORARY STACK 

The temporary stack (temp stack) is a block of core storage 
associated with a particular task and is used by Monitor ser- 
vice routines for temporary storage to achieve reentrancy. 
An entry in the TCB for a task points to the temp stack 
space. When a task is active and using either Monitor ser- 
vice routines or the floating accumulator (defined below), 
the beginning of the temp stack space for the active task 
must be set into core memory location 6 (after the previous 
contents of location 6 are saved). Monitor service routine 
M:SAVE will set this pointer. 

When Monitor service routines or Public Library routines 
need temporary space, they can call M:RES to reserve space, 
and M:POPmust then be called to release the space when it 
is no longer needed. Thus, the total temp stack is a func- 
tion of the deepest nesting of calls to Public Library routines 
and RBM service routines and of the space required for 
these routines. 



FLOati MQ ACCUMULATOR 

This software convention is used extensively by mathematics 
library routines and can also be used by any user's program. 



Nonresident foreground programs are real-time programs 
not needed in core on a continuous basis. They are created 
like resident foreground programs and are then written on 
the RAD in the user processor (UP) area. An operator or a 
resident real-time program can later call one of these non- 
resident programs, and it will be loaded and executed like 
a permanently resident real-time foreground program with 
all the protection and priority privilege characteristics of 
the foreground. 



COMPRESSED RAD FILES 

EBCDIC character codes do not use all possible bit combi- 
nations of an eight-bit byte, and some combinations (X'FC 
and X'EC) are therefore available for special coding bytes. 
Since EBCDIC information often contains a large number 
of "blank" byte strings, a code and a word count are used 
to replace an entire string of blanks. Thus, several 80-byte 
source cards (usually about 12) can be compressed and 
blocked into a 360-byte RAD sector. The RBM Read and 
Write routines provide the compression or decompression 

fanfiira rtr\A fko iirAf **.***. *■*-*•.*** ***••*■* ~^<.*.J ^i.. ,,,..!4.~ ~*. 4-L,t. L 

,^—,wiv-, «,i^ i,,v, \j&^, |_,, wy, uill S.VJI1 I CUU Ul VYIIIC UJ I I Iv-'uCjl I 

the file contained 80-byte card images. Compressed files 
are always blocked; that is, several records are transferred 
with one RAD access. 
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2. CONTROL COMMANDS 



The Monitor is controlled and directed by control commands 
that initiate loading and execution of programs and provide 
communication between a program and its environment. 
The environment includes the Monitor, background proces- 
sors, the operator, and peripheral equipment. 

Control commands have the general form: 



[mnemonic specification 



! is the first character of the record and identifies 

the beginning of a control message. 

mnemonic is the mnemonic code name of a control 

function or the name of a processor. It must 
immediately follow the ! character without inter- 
vening spaces. 

specification is a listing of required or optional 

specifications. This may include labels and nu- 
meric values appropriate to the specific command. 
In the specification field, hexadecimal values 
must be shown as +xxxx and EBCDIC values must 
begin with a letter; any other values are assumed 
to be decimal values. Specification fields are 
separated by a comma or an equals sign. 

In this manual the options that may be included in the 
specification field of a given type of control command are 
shown enclosed in brackets although brackets are not used 
in actual control command format. 

One or more blanks separate the mnemonic and specifica- 
tion fields, but no blanks may be embedded within a field. 
A control command is terminated by the first blank after 
the specification field. Annotational comments detailing 
the specific purpose of a command record may be written 
following the specification terminator, but not beyond col- 
umn 72. Only columns 1-4 are examined to determine the 
control command. 

The user may insert comment lines within a fob stack at any 
point where a Monitor control command would be recog- 
nized. A comment line contains an asterisk as the first 
character of the line. The comment line is listed on the 
LL device. 

Communication between the operator and the Monitor 
is accomplished via control commands, key-ins, and 
messages. Control commands are usually input to the 
Monitor via punched cards; however, any input device(s) 
may be designated for this function (see ! ASSIGN com- 
mand). Control key-ins are always input through the 
keyboard/printer. All control commands and Monitor 
messages are listed on the output device designated as 



the listing log (normally a line printer) to provide a 
hard-copy history of a fob. 

JOB CONTROL PROCESSOR (JCP) 

Monitor control commands are read from the background 
operational label CC unless the operator has requested a 
keyboard/printer override through an unsolicited KP key-in. 
All such commands are read by the Job Control Processor 
(JCP), a special processor loaded into the background by the 
RBM and reloaded into the background following each 
job step within a job. When a control command is en- 
countered by the JCP, the order of search is 

1. Monitor service commands. 

2. System processor names. 

3. User processor names. 

4. Foreground processor names. 

5. Background processor names. 

A !JOB command sets all background operational labels to 
their standard assignments. All temporary RAD space is set 
"unused" and is then available for following job steps. 

As the JCP encounters ! ASSIGN and ! DEFINE commands 
between job steps, it makes appropriate entries in the oper- 
ational label tables and continues to do so until it encoun- 
ters a request for a processor. When the requested processor 
is read into the background and attains control, this marks 
the beginning of a job step. 

At the end of each job step (i.e. , when the JCP begins 
reading control commands at the completion of the previous 
job step), all background operational labels associated 
with temporary RAD space are set to an undefined status 
and all temporary background space is reset to an "unused" 
status unless a ITEMP S control command is in effect, which 
saves temporary files until a 'TEMP R, !JOB, or !FIN com- 
mand is encountered. 



MONITOR CONTROL COMMANDS 

ABS The !ABS control command causes the Absolute 

Loader to read absolute binary programs from the AI device 
and write core image copies onto the OV file. The last 
(or only) segment to be read must be followed by an ! EOD 
command. The binary program(s) following the !ABS com- 
mand must contain only those load items that are part of the 
Sigma 2/3 Absolute Object Language. The program can be 
a background program, a processor for the background, or 
a real-time foreground program. 

A subsequent !XEQ command causes the RBMsubtask SrLOAD 
to load the core image of the root segment (segment number 0) 
from OV into core storage. Subsequent segments (1 - n) 
are loaded by the root through the use of MrSEGLD. 
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When an !ABS control command is encountered, the 
Absolute Loader reads the absolute deck that follows from 
the AI device and writes the core image copy onto the file 
to which the OV operational label is currently assigned. 
If OV has not been assigned, it will be assigned by default 
to the RBMOV file on the RAD. The program can be exe- 
cuted from a permanent SP (system processor) or UP (user 
processor) file either by inputting a "Iname" command 
(where "name" is the name of the file on which the program 
was written), or an !XEQ command. 

If a multisegment program is loaded, the Absolute Loader 
creates an OVrLOAD table at the end of the root. The root 
must always be the first load module and each succeeding 
load module is assigned a consecutive segment identifica- 
tion number, with the first succeeding segment starting 
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dress will be at its origin location and its entry address will 
be the transfer address generated by the !END card image. 

The form of the !ABS control command is 

/lABS [sizelCoplbJOplb.]. . .[,o P lb ] 



labels for the background are reset to the standard values 
at the beginning of a job by the Job Control Processor, an 
operational label assignment is in effect only until the next 
! JOB command is encountered or until it is again reassigned. 

An operational label is a two-character name that is used 
as a label in referring to a device-file number. The con- 
vention of operational labels is used for the processors or 
any other program to make them device-independent, and 
also to give some mnemonic value to the input/output opera- 
tions associated with the processors. 

Device file numbers are a logical means of referring both 
to a physical peripheral device and to a collection of in- 
formation about that device; that is, the current file of 
information. Device file numbers are defined sequential iy 
^ana remamea nxeuj in inc ulv!v.l i ill. umi w |ajiuimcici 
during SYSGEN (see Table 27). 

Standard operational labels can be reassigned to different 
device-file numbers during SYSGEN or through ! ASSIGN 
and ! DEFINE control commands. Two tables of operational 
labels are maintained by the system; one is used for back- 
ground (see Table 2) and the other for foreground. Device 
unit numbers (see Table 3) are also stored in the same two 
tables in the form of binary integer values. 



where 



size is an optional parameter for background pro- 

grams only. It specifies the temp stack size 
required for the background program being 
loaded. If size is omitted, a temp stack size 
equal to the maximum size needed for all Monitor 
service routines (80) will be used. The temp stack 
will always be allocated at the start of back- 
ground, and it is the user's responsibility to origin 
his program above the temp stack. For foreground 
programs, the size parameter is ignored and the 
temp stack pointers must be assembled as part of 
the program (i.e., in the TCB). 

oplb] ,oplb2 . . . are operational labels used by the 
program that require blocking buffers (i.e. , those 
labels that may be assigned to blocked RAD files). 
A maximum of 10 operational labels may be speci- 
fied. When the program is loaded from the RAD 
for execution, the Monitor will ensure that enough 
block buffers are available for these specified 
labels assigned to blocked files. 

Programs loaded under the Absolute Loader are subject to 
the following restrictions: 

• No external references are permitted. 

• The program must be in absolute form. 

• Relocatable code may not be imbedded. 



ASSIGN The ! ASSIGN control command causes either a 

new or standard operational label to be equated with a 
specified (or temporary) file number. Since operational 



Table 2. Standard Background Operational Labels 



Operational 
Label 


Explanation 
of Reference 


I/O Device 


AI 


ABS binary input 


CR,PT,MT,RD 


BI 


Binary input 


CR,PT,MT,RD 


BO 


Binary output 


CP,PT,MT,RD 


CC 


Control command 
input 


KP,CR,PT,MT, 
RD 


DO 


Diagnostic output 


Same as LO 


GO* 


Execution input (GO) 


CR,MT,PT,RD 


ID* 


Debug ident file 


RD 


LI 


Library input 


Same as BI 


LL 


Listing log 


Same as LO 


LO 


Listing output 


LP,KP,MT,RD 


OC 


Operator's console 


KP 


OV* 


Overlay (temporary) 


RD 


4-t 
PI" 


Processor inout 


RD 


PM 


Punch RBM 


CP,PT,MT 
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Table 2. Standard Background Operational 
Labels (cont.) 



Operational 
Label 


Explanation 
of Reference 


I/O Device 


SI 


Symbolic input 


KP,CR,PT,MT, 
RD 


S2* 


Sigma 2/3 procedures 


RD 


UI 


Update input 


CR,PT,MT,RD 


UO 


Update output 


PT,MT,RD 


xi m 


Overlay Loader, 
Extended Symbol 


MT,CR,RD 


X2 m 


Overlay Loader, 
Extended Symbol 


RD 


X3 m 


Extended Symbol 


RD 


X4 


Utility (verify) 


RD,MT,CR,PT 


X5 m 


Utility (prestore) 


RD 


These operational labels, if required by a processor, 
are automatically assigned to permanent files in the 
system data area by the Job Control Processor. 


The PI operational iabel is assigned to fiies in the 
System Processor and User Processor areas by the Job 
Control Processor. 


These operational labels are automatically assigned 
to background temporary RAD files, with the file defi- 
nition appropriate to the background processor being 
executed. These definitions are made from a table in 
the Job Control Processor that is selected by the first 


three characters of the processor name. 



The standard foreground operational labels are as 
follows: 



Operational Explanation of 

Label Reference 



BO 
AL 



Binary output 
Accounting log 



I/O Device 

CP,PT,MT 

RD 



An assignment to file zero means that the operational label 
is not effective, and all references to this operational label 
result in a no-operation until it is reassigned. Note: some 
background processors (e.g., Utility) do not allow use of 
active operational labels assigned to file zero. See 
Appendix E for a complete description of operational label 
usage. 



! ASSIGN commands can appear anywhere within the con- 
trol command stack (except within a job step) and take 
effect immediately. That is, if the CC operational label is 
reassigned, the very next control command is read from the 
newly assigned device (unless the KP override has been 
imposed by an unsolicited key-in). The 'ASSIGN com- 
mand is used for both foreground or background operational 
labels. (The operator must key in FG before assigning a 
foreground operational label.) 



There are three forms of the ! ASSIGN command. Form 1 is 

A 



IASSIGN oplb=file-number[,F] 



oplb is either a two-character alphanumeric name 

in the foreground or background operational label 
table (or is to be placed in the table), or a 
FORTRAN device unit number, indicated by the 
prefix F: preceding the device unit number (see 
Table 3). 

file number is the device-file number for a physical 
device in the system (created at SYSGEN). 

F when present, declares that the assignment is to 

be included in the foreground operational label 
table. Otherwise, it is assumed to be in the back- 
ground operational label table, and the file num- 
ber must also be a background file number. 

Form 2 of the IASSIGN command is 
/ IASSIGN oplb=filename,area[, F] 

where 

oplb is an operational label or a device unit num- 

ber identified by the F: prefix. 

file name is the name of an existing RAD file. The 

RAD file is rewound if it is blocked or compressed. 
Only permanent RAD files can have a file name. 
Once the file name is entered in the dictionary 
by SYSGEN or RAD Editor, an IASSIGN control 
command or call to M:ASSIGN can equate either 
an operational label or FORTRAN device unit 
number to this file name. 

area mnemonic specifies the area to search for the 
file name from the areas listed in Table 4. 

F indicates that the assignment is to be included 

in the foreground operational label table. 
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Table 3. Standard Device Unit Numbers 



Device Unit 




Number 


Standard Assignment 


101 


Keyboard/printer input 


102 


Keyboard/printer output 


103 


Paper tape reader 


104 


Paper tape punch 


105 


Card reader 


106 


Card punch 


108 


Line printer 



Table 4. RAD Area Mnemonics 



Code 


Meaning 


SP 


System Processor area 


SD 


System Data area 


SL,UL 


System and User Libraries 


UP,FP,BP 


User, Foreground and Background 




Processor areas (user tasks and pro- 




grams and background processors) 


BT 


Background Temp Area 


CP 


Checkpoint area 


aa 


Data area(s) 


Xn 


Similar to aa areas but no disk pack 




verification performed 



Form 3 of the ! ASSIGN command is 



IASSIGN oplb^plb 



wh( 



oplb 



is as defined above. 



F if present, indicates that both operational iabels 

are foreground; otherwise, both operational labels 
must be background labels. 



Examples: 



Form 1; 



Form 2: 



IASSIGN SI = 3 
IASSIGN F : 105 =3 
IASSIGN OV=FILEl, UP 

IASSIGN LI =BI 



ATTEND The IATTEND control command indicates that 

RBM is to go into a wait condition on any abort from the 
background, and then read and process the next control com- 
mand encountered when background processing continues 
after an unsolicited key-in. Its primary purpose is to offer 
improved recovery procedures. If an abort occurs without 
this control command being specified, JCP will reset the 
CC operational label to the standard value, skip all con- 
trol commands, binary records, or data until it finds a 
new ! JOB, ! PURGE or !FIN command, and will not pause 
for operator intervention. In this "skip" mode, all EBCDIC 
records beginning with ! will be listed on the LL device, 
with an indication ('>' preceding the command) that they 
are ignored. This is the normal mode for closed-shop batch 
processing, without halts between jobs after aborts. 

The form of the command is 
/[ATTEND 



It exists for one job only, and usually immediately follows 
the !JOB command. 



C: The !C: control command connects the designated 

real-time foreground task to a specified interrupt location, 
optionally armed and enabled as specified by the control 
code. The task may also be triggered by means of this con- 
nect operation if the code is equal to seven, providing that 
the task has previously been armed (i.e. , with a previous 
!C: command, an !XEQ or "Iname" command, or by a 
Q key-in). 

The form of the !C: control command is 

/ !C: tcb[,code] 



wh< 



tcb is the address of the Task Control Block for 

this task. If the value is hexadecimal, it must be 
shown as +xxxx. If the Overlay Loader initializes 
the TCB by means of the TCB parameters, it does 
so completely, using ioad information and values 
on the TCB and BLOCK cards. No partial initiali- 
zation of a TCB is allowed with the-exception of 
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the blocking buffer pool. If a user builds his own 
TCB, the TCB must begin at the execution location 
plus the "temp" value specified on the Overlay 
Loader !$ROOT command. 

code when present, is the interrupt operation code. 
It overrides the initial TCB task code; a code of 
7 triggers the task if it is armed. 

Note: If "code" is not specified, the code given 
in the TCB will be used. 

The !C: command does not change the contents of the TCB. 



CC The ICC control command returns control to the cur- 

rently assigned CC device and nullifies the effect of a 
previous KP key-in. The control command is honored 
regardless of whether or not the "skip" mode is in effect. 
The "skip" mode is cleared following this command. The 
form of the command is 



ICC 



DEFINE The ! DEFINE control command allocates a 

portion of the background temporary RAD space for a spe- 
cific operational label or device unit number by assigning 
the operational label to an unused device-file number, 
which in turn is linked to the specified portion of the RAD. 
Since temporary RAD files are not maintained by the Moni- 
tor, they have no name and are identifiable only by the 
operational label for which each file was created. The 
(DEFINE control command must precede the specific pro- 
cessor or user program to which it applies, since this tem- 
porary space is reset at the beginning of each |ob and at 
the subsequent reloading of the JCP (unless a ITEMP S 
control command is in effect). That is, the files are de- 
stroyed and the RAD space and all device-file numbers 
linked to it may be used by the next job. 

The form of the 'DEFINE control command is 



IDEFINE oplb,nrec,srec 



/here 



oplb is an operational label or a FORTRAN device 

unit number (with a prefix of F:). 

nrec is the number of logical records in the file. 

srec is the logical record size, in bytes. 

R defines the file asan unblocked random-access file. 

P defines the file as a blocked random-access file. 



U defines the file as an unblocked file. 

C defines the file as a compressed EBCDIC file. 

B defines the file as a blocked file. 

If neither R, P, U, nor C is specified, the file is defined as a 
sequential, noncompressed, blocked file. If R is input, srec 
is used as the granule size. 



EOD Sections may be defined in a user's deck by insert- 

ing !EOD control commands at the end of each section. 
When an !EOD command is encountered, the Monitor re- 
turns an EOD status (when using the MrREAD I/O routine). 
This is similar to a tape-mark on magnetic tape. Any num- 
ber of !EOD control commands may be used in a fob wher- 
ever desired by the user. 

The form of the ! EOD control command is 

!EOD 



FIN The ! FIN control command specifies the end of a 

stack of fobs. When the I FIN control command is encoun- 
tered, the Monitor writes it on the listing log to inform the 
operator that all current fobs have been completed and also 
writes I 'BEGIN IDLE on the OC device. The Monitor then 
enters the idle state. 



The form of the IFIN control command is 

A 



!FIN 



FSKIP,FBACK,RSKIP,RBACK The file positioning con- 

trol commands, IFSKIPand IFBACK, forward or backspace 
the specified device (magnetic tape or sequential RAD file) 
immediately past the next file mark, or past the nth file 
mark if n files are specified (n = 1 for RAD files). IRSKIP 
and IRBACK perform similar functions but act on records 
rather than files. IRBACK does not apply to compressed 
RAD files. 

The forms of the control command are 



IFSKIP 
IFBACK 
IRSKIP 
IRBACK 



device[, number] 



device is the device indicator of the device to be 

positioned and is restricted to background devices. 
The device indicator is one of the following: 

1. A device-file number, shown as a decimal 
integer. 
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2. A FORTRAN device unit number, shown as 

F:n 

where n is a decimal integer equal to the de- 
vice unit number. 

3. An operational label, shown as two alpha- 
numeric bytes, the first of which isaiphabetic. 

number is the number of operations to be performed; 
if absent, one operation is assumed. 

HEX The !HEX control command loads patches at execu- 

tion time for either the Monitor itself or any user program. 
(See Appendix G for input description.) 

The form of the !HEX control command is 

A 



The form of the ! JOBC control command is 

A. 



HEX 



JOB The !JOB control command signals the beginning 

of a new fob. The background operational labels and 
FORTRAN device unit numbers are set to their standard 
assignments as defined at System Generation. All RAD 
temp files are closed. 



This command always causes a page to be ejected on the 
LL device before the command is listed. The version of 
the RBM being utilized will be inserted following the last 
field on the UOB command. 



The form of the ! JOB control command is 
/ UOB [name, account] 



name has a limit of 12 characters, 
account has a limit of six characters. 



JOBC The !JOBC control command indicates a con- 

tinuation of the current job. !JOBC closes all RAD temp 
files and resets all background operational labels to their 
standard assignments (with the exception of "CC"). The 
! JOBC command does not clear the "attend" flaa or the 
"skip" mode, nor does it terminate the effect of an FG or 
SY key-in. (A useful application of the ! JOBC command 
is given in the Utility job deck example in Chapter 10.) 



!JOBC 



LIMIT The 'LIMIT control command is used to set a 

maximum on the execution time of a background program. 
This command is effective only if the system has real-time 
Clock 1 dedicated to the Monitor. If the job exceeds the 
time limit, the job is aborted (TL) and is terminated with a 
postmortem dump (if that option was specified). 

The form of the ! LIMIT control command is 

! LIMIT [N] 



where N is the maximum allowable execution time in min- 
utes (0 < N < 6000). 

MESSAGE The ! MESSAGE control command is used to 

type a message to the operator. It is useful for messages 
concerning mounting tapes or setting certain device or 
Control Panel conditions. The command is listed on the 
OC device. There is no response. 

The form of the ! MESSAGE control command is 

A 



[MESSAGE message 



where message is any comment to the operator, up to the 
full-card image size (total of 72 columns per card). 



PAUSE The ! PAUSE control command temporarily sus- 

pends background operation to allow the operator time to 
complete the fob setup. Background operations resume when 
the operator performs an unsolicited S key-in. The command 
is listed on the OC device. 



The form of the ! PAUSE control command is 
A \ PAUSE message 



where message is a comment to the operator, up to the full- 
card image (total of 72 columns per card). 



PMD The ! PMD (postmortem dump) command causes the 

Monitor to dump the registers, pl'us selected areas of mem- 
ory, at the end of a fob step. The dumps are always onto 
the background DO device in specified format. The !PMD 
command is only effective for one fob step. 
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The form of the ! PMD command is 

/iPMD [u][,ALL[,format]][,fwa,lwa[, format]] 



The form of the ! PURGE control command is 



c 



3 



L, f wa, I waL, format]] 



/here 



U indicates that PMD is to be entered regardless of 

the manner of background termination. Otherwise 
PMD is entered only if background terminates 
abnormally. 

ALL indicates that all of background is to be 

dumped. If ALL is not specified and no other 
limits are specified, only the CPU registers are 
dumped. 

fwa/ Iwa specifies the dump starting and ending 
locations. These values are hexadecimal if pre- 
ceeded with a plus (+) character. 

format specifies the dump format as follows: 

H Hexadecimal (default, if format 

unspecified) 

M Mnemonic 

I Integer 

E EBCDIC 

When a format of E is specified, each dump line 
will consist of hexadecimal values followed by 
EBCDIC translations, at the end of the line. Four 
limit pairs (fwa, Iwa) may be specified. The 
CPU registers are always dumped, regardless 
of the limits. 

An X (abort) key-in will terminate all postmortem dumps 
if performed while PMD is active. 



/SPURGE [C] 



where C is the directive to clear the accounting file (must 
be preceded by an unsolicited SY key-in). 



REL Relocatable binary program modules to be loaded 

onto the GO file are preceded by an !REL control com- 
mand. The binary modules that follow must be in Sigma 2/3 
Standard Object Language. The modules may constitute 
a complete program, a root, or segments of a program. 
Checksum and sequence checks will be preformed. 

The form of the !REL control command is 



!REL 



The modules are copied onto the file to which GO is cur- 
rently assigned. If GO has not been assigned, it will be 
assigned by default to the RBMGO file on the RAD, which 
is rewound before the modules are copied. Several modules 
may be copied through the use of one !REL control command 
by stacking the modules. The final module must be fol- 
lowed by an !EOD control command that will cause the 
JCP to write an end-of-file (EOF) onto GO and then 
backspace one file. In this manner the GO file is 
positioned to accept additional input, but is always 
terminated by an EOF. The relocatable binary decks are 
loaded from operational label BI. 

The 4 REL control command is a convenient method of 
obtaining additional hard copies of object modules pro- 
duced on GO by Extended Symbol or FORTRAN. By as- 
signing BI to GO and then reassigning GO to BO, modules 
will be copied from the original GO onto BO up to and 
including the EOF. BI should be rewound before each 
!REL command. 



PURGE The ! PURGE control command is used to output 

the contents of the accounting file. The output is to back- 
ground operational label LO in the following format: 

MM/DD/YY HRMN NAME ACCOUNT TIME 

(MMMM. MM) 

An option is provided to clear the accounting file sub- 
sequent to this output. In this manner the user could assign 
background operational label LO to a device such as the 
card punch or the paper tape punch, and by exercising the 
"clear" option, could produce a periodic hard copy of 
the accounting file and clear the accounting file for 
future use. A ! PURGE command will always be acknowl- 
edged even in the "skip" mode. 



REWIND The ! REWIND control command rewindsa mag- 

netic tape or a sequential RAD file and has no effect on 
other devices. The operation takes place immediately 
after the command is interpreted. The command is re- 
stricted to background files. 



The form of the ! REWIND control command is 
/ {REWIND device 



where device is the device indicator (as in IFSKIP) of the 
device to be rewound. 
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TEMP Normally, the temporary background space on 

the RAD is reset at the completion of each step within a 
job, so that a separate assembly and compilation can each 
have full access to this temporary area for scratch space 
as needed. The STEMP control command is a means of 
altering this standard procedure. When used with the 
save (S) option, temporary files are not released after any 
job step within a job stack until either a 1TEMP command 
is encountered with a reset (R) option or the next !JOB, 
! JOBC, or !FIN command is encountered. 

The form of the ITEMP control command is 



A EMP (r) 



where either S or R is required 

S means to save RAD temporary files between job 

steps within a job (e.g., between an assembly 
and a concordance). 

R means to reset the RAD temp files after each job 

step. 



UNLOAD The ! UNLOAD control command causes a 

specified magnetic tape or sequential RAD file to be re- 
wound in manual mode. Operator intervention is required 
to use the device again. If the device is a sequential RAD 
file, the file is rewound to BOT and released by a call to 
MrCLOSE. The command is restricted to background files. 

The form of the ! UNLOAD control command is 

! UN LOAD device 



where device is the device indicator (as in 1FSKIP) of the 
file to be rewound off-line. 



WE OF The IWEOF command writes the appropriate end- 

of-file mark on the output device. The command is re- 
stricted to background files. For magnetic tape, it is 
a tape mark; for the card punch or paper tape punch, 
it is an !EOD command; and for sequential RAD files, 
it is a logical file mark. 



The form of the IWEOF control command is 
/ IWEOF device[, number] 



number is the number of end-of-files to be written. 
If absent, one end -of-file is written. 



XEQ The !XEQ control command loads the first program 

from whatever file the OV operational label is currently 
assigned to. For foreground programs, the command must 
be preceded by an FG key-in. 



The form of the !XEQ command is 

A 



!XEQ 



XED The !XED control command performs the same 

operations as the iXEQ control command except that !XED 
transfers control to RBM Debug through the entry point 
D:KEY when the root segment has been loaded. The mes- 
sage ! IDKEY-IN will appear on the keyboard/printer and 
the user can then input Debug control commands. (See 
Chapter 12 for a discussion of RBM Debut.) The !XED 
control command causes the background operational label 
ID to be default-assigned to the RBMID file on the RAD 
if it is not already assigned. 



device is the device indicator (as in 1FSKIP) 

of the device that is to have an end-of-file writ- 
ten on it. 



The form of the !XED control command is 
/ !XED 



PROCESSOR CONTROL COMMANDS 

System processors on the System Processor area and any user 
background or foreground program residing in the User Proces- 
sor, foreground or background program areas can be called by a 
processor control command. The commands have the format 

! processor parameters 



/here 



processor is the file name of a processor which must 

be distinguishable in the first three characters from 
system control commands (see Table 5). 

parameters are optional parameters interpreted by 
each particular processor. 

When a processor control command is read and interpreted 
by the Job Control Processor, the root segment of the speci- 
fied subsystem is loaded from the RAD into memory. The 
JCP will assign all permanent RAD files used by the speci- 
fied processor before the processor is executed unless these 
files were previously assigned via IASSIGN commands. The 
JCP will also define ali temporary operational iabeis used 
by the processor (by defining them as background temp 
files) unless they are previously defined via ! DEFINE com- 
mands. JCP then transfers control to the processor. 
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Table 5. RBM System Processors 



Name* 


Description 


! FORTRAN 
ICONCORDA 

lOLOAD 
! UTILITY 
IXSYMBOL 
! RAD ED IT 


Basic FORTRAN IV Compiler 

Concordance Program for 
Extended Assembler 

Overlay Loader 

Utility 

Extended Symbol Assembler 

RAD Editor 


The RBM System Processor names are entered into 
the System Processor area dictionary with the RAD 
Editor !*ADD command. If the file name is less 
than eight characters, the name on the processor 
control command must exactly match the file name. 
If the file name is eight characters (maximum), the 
first eight characters of the name on the processor 
control command must exactly match the file name. 
Trailing nonblank characters beyond the eighth 
character in the processor control command name 
are ignored. 



When a requested processor is read into the background 
and attains control, this marks the beinning of job step. 
An example of a job stack illustrating its breakdown by job 
step is shown in Figure 2. 



EXTENDED SYMBOL CONTROL COMMAND FORMAT 

The Job Control Processor reads and interprets the 
IXSYMBOL control command and loads the Extended Sym- 
bol assembler from the RAD into background memory. The 
assembler continues to assemble programs until it encounters 
an end-of-file. The Extended Symbol assembler is called 
into operation with the command 

IXSYMBOL [option.., option-, — , option ] 



where option can be 

BA specifies batch assembly mode. XSYMBOL will 
ignore single end-of-files and will terminate only 
when two consecutive end-of-files are encountered. 

BO specifies binary output. 



Job Step 




IFIN 



IEOD 



!*REWIND UI 



l*COPY F, ALL, FORM 



!*OPLBS LO 



! UTILITY COPY 



'ASSIGN LO=2 



[ASSIGN UI=10 



{REWIND LO 



Job Step 




!EOD 



X 



i 



Source Deck 




IXSYMBOL LO,CR 



1REWIND 10 



! ASSIGN LO=10 



! ATTEND 



"JOB 



J 



Monitor enters 
"Idle" state. 



JCP is read into 
background 

Utility is read 
into background. 



JCP is read into 
background. 



Extended Symbol 
is read into 
background. 



Figure 2. Job Stack Example 



Proccessor Control Commands 



17 



CR specifies cross-reference listing. 

DW specifies display warnings. 

GO specifies output GO file. 

LO specifies list assembly output. 

NP specifies no standard procedure input. 

NS specifies no summaries. 

PP specifies punch standard procedure file. 

SL specifies simple literals. 

Any number of options may be specified and in any order. 
If no options are specified, the following options are 
assumed by default: 

BO,GO,LO 

The presence of any nondefault option requires that any 
desired default options (except SI which is always defaulted) 
must also be present. 



BASIC FORTRAN IV CONTROL COMMAND FORMAT 

The Job Control Processor reads and interprets the ! FORTRAN 
control command and loads the Basic FORTRAN IV compiler 
from the RAD into background memory. The compiler is 
called into operation with the command 



! FORTRAN [S.,S -,..., S ] 



l'~2' 



where S. can be 
i 

LO specifies an object listing. 

LL specifies an object listing with data chains. 

XP specifies extended precision real data instead 

of standard precision. 

ALL specifies that multiple files are compiled. 

FORTRAN will ignore single end-of-files and 
will terminate compilation only when two con- 
secutive end-of-files are read. 



Binary output is normally output on both the BO and GO 
devices. To suppress the BO or GO output, the user must 
assign the pertinent operational labels to (see 'ASSIGN 
and ! DEFINE control commands in this chapter). 

If no specifications are present, binary output on the BO 
and GO devices, a source listing, and standard precision 
mode are assumed by default. 



RBM/PROCESSOR INTERFACE 

Ground rules common to all system processors are: 

• All processors operate in the background. 

• With the exception of the UTILITY program, processors 
must use standard background operational label table 
assignments for their I/O requests. (See Table 2 for 
the standard background operational labels.) 

• The first character of each line of the listed output 
from the processors is always interpreted as a vertical 
format character (carriage control) and is never printed. 
The RBM I/O routines treat the vertical format properly 
for the keyboard/printer, Hne printer, and magnetic 
tape. 

• When the RBM transfers control to a background pro- 
cessor, the X register contains the address of the con- 
trol card image, providing access to any parameters. 

• At the completion of an assembly or compilation, the 
processor writes two end-of-files on the LO device, 
and then backspaces the LO device one file. The 
M:CTRL routine will treat these operations for the 
devices as described in the I/O section. This permits 
file processing of output on magnetic tape, if LO is 
assigned to magnetic tape. The processor writes an 
EOF on BO and GO at completion and then back- 
spaces one file (GO and BO are separate options). 

• The processor generally returns control to RBM by 
means of a call to M:TERM. RBM will immediately 
read from CC and if there is another control command 
for the current processor, it will reload the processor 
from the RAD. 



it overlay loaaing is requirea, tne processor uses 
M:SEGLD. The overlay operational label for the 
background is PI. 

If an irrecoverable error occurs, the processor exits 
to RBM with a call to M:ABORT and displays the abort 
code in the X register and the abort location in the 
A register. 

Since all standard RAD files are defined by the Job 
Control Processor, the processors need not call 
M:DEFINE, but must call M.-CLOSE to release blocking 
buffers in those cases where several RAD files are used 
but are not all open at one time. 

The first ouput line to LO from an assembly or com- 
pilation causes a page eject. 



GO AND OV FILES 

Figure 3 shows how the JCP and Extended Symbol or Basic 
FORTRAN IV use the operational labels GO and OV. The 
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0. 



Relocatable binary decks 
copied directly from BI to 
GO by JCP with anlREL 
control command. 




















Assembler or compiler out- 
put to both GO and BO. 











Overlay Loader takes 
input from GO to form 
executable OV. 



JCP forms executable pro- 
gram directly from AI to 
OV with an SABS control 
command. 





Executable program; called 
by !XEQ command; loaded 
by RBMsubtask M:LOAD. 



Figure 3. Use of GO and OV Files 



GO and OV files are the files to which these operational 
labels are assigned by the JCP and are standard default 
files when no operational labels are specified. The GO 
file is a blocked, sequential file that contains relocat- 
able binary decks read from the fob stack, and binary 
ouput produced as a result of an assembly or compila- 
tion. After each module is loaded onto the file, an 
end-of-file mark is written and a backspace file is per- 
formed. Thus, at any point within a job stack the 



GO file contains all modules that have been loaded and is 
in position to accept others. 

The Overlay Loader may now use the contents of the GO 
file to create an executable core image program and save 
this program on the random-access OV file. Absolute bin- 
ary decks produced by an assembly may also be written (in 
executable core image form) onto the OV file by JCP 
through use of the !ABS command. 
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3. OPERATOR COMMUNICATION 



SYSTEM COMMUNICATION 

When events take place in the system that require operator 
intervention, or when one job is completed and another fob 
begins, RBM informs the operator of these conditions by 
messages on the keyboard/printer. All such messages from 
the Monitor begin with two exclamation marks (! !). 



is defined as a change from manual to automatic, or from 
automatic to manual and back to automatic, depending on 
the initial condition.) When the change of state is sensed, 
the operation is retried. Thus, if the device is EMPTY, it 
need only be placed in the automatic mode. If there is a 
PUNCHES error or a FAULT on the card reader, the reader 
is unloaded, the bad card is corrected and replaced, and 
the reader is returned to the automatic mode. 



Generally, these messages require no operator response on 
the keyboard/printer but may indicate that some peripheral 
device needs attention. In some cases, the operator must 
interrupt and key in a response after correcting the speci- 
fied problem. 



I/O RECOVERY PROCEDURE 

If a message concerns an I/O error condition, the Monitor 
I/O routines that generated the message will be waiting to 
sense a change of state in the device. (A change of state 



MONITOR MESSAGES 

The messages itemized in Table 6 are output on the OC de- 
vice. They are primarily for background program use but 
can be used by foreground by specifying standard error re- 
covery and "initiate and wait" in the MrREAD, M.-WRITE, 
or MrCTRL calling sequence. 

Real-time programs with special requirements can inform 
the operator of special conditions and wait for an oper- 
ator response. 



Table 6. Monitor Messages 



Message 


Meaning 


UALIO ERROR 1 
! !BEGIN WAIT 


An irrecoverable I/O error has occurred while accessing the ac- 
counting file, normally because of a hardware failure or unavaila- 
bility of operational label AL. The correct assignment of this 
operational label is to RBMAL,SD. An attempt should be made to 
recover the contents of the accounting file as stated above. If 
this recovery fails, the operator may gain control through a KP 
key-in and then as FG key-in to allow foreground modifications; 
the foreground operational label AL may then be reassigned (e.g. , 
! ASSIGN AL = RBMAL,SD,F or .'ASSIGN AL = 0,F). 

Note: Assignment of the foreground operational label AL to zero 
will inhibit the logging of job stack entries into the 
accounting file. 


!!AL OVERFLOW* 
!! BEGIN WAIT 


The accounting file (RBMAL) cannot accept another entry. The 
accounting file is allocated at SYSGEN and accommodates 
74 entries. (The user may increase or decrease this capacity via 
the RAD Editor.) At this point, normal error recovery will be a 
key-in of KP to gain keyboard/printer control. Next, a key-in 
of SY will permit access to the accounting file. The operator 
should now assign the background operational label LO to a hard- 
copy device (e. g. , paper tape, card punch). Input of a ! PURGE 
control command specifying the clear option (i.e., ! PURGE C) 
causes the contents of the accounting file to be copied onto that 
device and clears the accounting file. The job stack causing the 
overflow can now be reentered. 


This alarm occurs only if the RBM accounting option has been exercised at SYSGEN. 
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Table 6- Monitor Messages (cont. ) 



Message 


Meaning 


! IATTEND ERROR xx 


JCP has read an erroneous control command while operating in the 
ATTEND mode, in which case RBM goes into a wait state after 
typing this message. After a subsequent S key-in, RBM will pro- 
cess the next control command. 


HBEGIN IDLE 


JCP has just read a !FIN card (which completes a fob stack) and 
background has gone into an idle state. Processing will resume 
on a new job stack following an unsolicited S key-in. 


! BEGIN WAIT 


The background has executed a WAIT request. An unsolicited 
S key-in will continue background processing. 


UBKG CKPT 


Background has been checkpointed as a result of a foreground pro- 
gram request. 


!!BK RELEASE,dtnn 


The specified device has been released for background use. 


HBKG RESTART 


Background has been restarted from its point of interruption. 


! 1BKGD xx ABORT, LOC yyyy 


The background job has aborted at location yyyy for the reason 
specified by abort code xx. If the Job Control Processor initiated 
the abort, a detailed explanation will be written on the back- 
ground DO device. 

If the system is operating in the "attend" mode (see IATTEND), 
RBM will perform any required postmortem dumps and then go into 
a wait state after an abort. After a subsequent S key-in, RBM 
will attempt to process the next control command from the CC 
device. 

If the system is not operating in the "attend" mode, RBM will not 
go into the wait state but will perform any required postmortem 
dumps and immediately begin reading from the CC device. All 
data cards and control commands will be skipped until a !JOB, 
IPAUSE, or !FIN card is found. Only a !JOB card will clear 
the "skip" mode. All control commands are listed on the LL de- 
vice with an indication (> character) preceding the command to 
show that they are being ignored. 


1!CCI 


JCP has begun to read control commands. This message occurs at 
the beginning of a job and between steps within a job (e.g. , when 
an assembly is completed). If CC is assigned to the keyboard/ 
printer (as a standard assignment, or after a KP key-in), the input 
light on the keyboard/printer will indicate that RBM is ready for 
input of a control command. 


! Idtnn EMPTY 


The device specified is in the manual mode and may be out of 
paper, cards, or tape. 


Ndtnn ERROR [,TRK xxxx] 


There has been a parity or transmission error on the device. If any 
automatic retries were specified, they will have been performed 
before this message is output. A CR device will indicate that an 
error card is in the output stacker. Recovery procedure is described 
above under "I/O Recovery Procedure". If it is RD, xxxx will be 
the errored track number. 
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Table 6. Monitor Messages (cont. ) 



Message 


Meaning 


!!dtnn FAULT 


Some condition on device type dt with physical device number nn 
(hexadecimal) has caused this device to become nonoperational. 
The recovery procedure is described above (in the discussion under 
change of state). The operation is automatically retried when the 
device goes into the automatic mode; it is neither necessary nor 
possible for the operator to type in a response. 


! Idtnn PUNCHES 


An invalid punch combination has been sensed on an EBCDIC 
image. 


! idtnn DATA RATE 


A data rate overrun has occurred. If any automatic retries were 
specified, they will be performed after this message is output. 


Mdl-nn UNROCOG 


Device type dt with device number nn (hexadecimal) is not recog- 
nized by the I/O routines. If the device is a magnetic tape unit, 
the requested drive may not be dialed in properly or power may be 
off in either the unit or the contoller. 


! Idtnn WRT PROT 


The RAD or magnetic tape is physically write-protected. If a 
RAD file is logically write-protected, this message will not ap- 
pear but appropriate status will be returned. 


MEND IDLE 


RBM has gone out of the idle state and will begin reading control 
commands from the CC device. Control commands will be ignored 
until a !JOB command is input. 


!!FG REQUEST, dtnn 


A request has been made to reserve the specified device. The 
operator should prepare the device and then reserve it through 
use of the FR key-in. 


MFG RESERVE, dtnn 


The specified device has been reserved for foreground use. 


! !FRGD xx ABORT, LOC yyyy TCB zzzz 


The foreground task with a TCB at location zzzz has aborted at 
location yyyy for the reason specified by abort code xx. The 
corresponding interrupt level will be disabled and if the task 
occupied nonresident foreground, an unload operation will be 
initiated. Background processing will continue. Because this 
message is written at the monitor priority level, only the abort 
message for one foreground task (the lower priority level task) 
will appear if two foreground tasks abort consecutively. 


! ! KEY ERROR, comments 


The Monitor could not process an unsolicited key-in response. 
The message usually indicates a format error on the key-in, 
where comments may be one of the following: 

NO AR The wrong disk pack was mounted for an 
M key-in and the area could not be found. 

DEVICE The channel for the device specified was 

not defined at SYSGEN or this device is not 
defined. Applies to M and BT key-ins. 



22 System Communication 



Table 6. Monitor Messages (cont. ) 



Message 


Meaning 


! ! KEY ERROR, comments (cont. ) 


IN USE If the key-in was an M (mount), the area 
must be removed. If the key-in was R 
(remove), files must be closed in the area 
(perhaps by an abort or unload). 

OVFLOW The Master Directory table length will not 
allow this key-in to be processed. 

DFN/OP The Device File table or Operational Label 
table has overflowed. 

IO ERR The device specified in the 'M' key-in 
cannot be correctly accessed. 

TEMP STACK The Temp Stack has overflowed. 


! ! MESSAGE comments 


A [MESSAGE control command has been read. The comments field 
may contain tape mounting or other instructions. RBM continues to 
read from the CC device after the message is typed out. 


! ! PAUSE comments 


A ! PAUSE control card has been read. The comments field may 
contain tape mounting information or other instructions. A control 
panel interrupt followed by an S key-in will cause RBM to continue 
reading from the job stack. 


!! POWER ON 


The system has experienced a power failure and the power-fail-safe 
option has been implemented. If the computer is a Sigma 2 of is a 
Sigma 3 with no external interrupt and no critical foreground tasks, 
or if the background or RBM Control Task was active, execution will 
continue; otherwise it will crash. If the latter case, the operator 
should reboot RBM from the RAD and restart the background. 


! Idtnn NOISE REC 


A noise record has been detected on magnetic tape and ignored. 
(A noise record is one that contains less than eight bytes and an 
irrecoverable parity error). 


Mdtnn BAD TAPE 


The magnetic tape mounted on device dtnn contains a bad spot that 
cannot be skipped when writing. The operator should mount a new 
tape and (if possible) rerun the fob. 1 



OPERATOR CONTROL 



Operator control of RBM is achieved by one of two meth- 
ods: solicited or unsolicited. 



example, ! IUKEYIN from a Utility program) and should 
always be directed to the operational label OC — Operator 
Communication. There is no standard fromat for the response 
to a solicited control. 



SOLICITED CONTROL 



UNSOLICITED CONTROL 



Solicited control will normally be in the form of a specific 
request from a foreground or background program (for 



All forms of unsolicited control are inflated when the 
operator activates the INTERRUPT switch on the Sigma 2/3 
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Processor Control Panel, 
of two forms: 



Unsolicited control may take one dfn is a decimal number specifying a legitimate 

device file number. » 



1. An unsolicited key-in request. 

2. A forced foreground disarm. 

The active foreground task will be disarmed and a call will 
be made to MtEXIT if all of the following conditions are 
true; otherwise, a key-in response will be requested: 

1. The value in the data switches has changed since the 
last activation of the Control Panel Interrupt (or since 
boot). 

2. The value in the data switches matches the address of 
the dedicated interrupt location of the current task, as 
specified in word 2 of the standard Task Control Block. 
See Table 17. Note that this implies that the active 
task must call M:SAVE. 

Conditions 1 and 2, when taken together, simply mean 
that the operator must intentionally enter the appro- 
priate value in the data switches; an accidental disarm 
cannot normally occur. 

3. The active foreground task (that is, the one to be 
terminated) must have a hardware priority lower than 
the Control Panel Interrupt level. 

If a forced foreground disarm is specified a foreground abort 
message will be written; otherwise the Control Panel Inter- 
rupt Task sets a flag in the RBM Control Task status word and 
triggers RBM. The Control Panel Interrupt Task then exits. 

When the RBM Control Task becomes the highest priority 
task in the system (that is, when all real-time foreground 
tasks are nonactive), it issues an output message 

! I KEY-IN 

and requests input (up to 20 characters) from the operator. 
Because of possible delays associated with messages to and 
from the operator, no devices used for time critical opera- 
tions should time-share an I/O channel used for operator 
communications. Each key-in must be terminated with the 
New Line ©code. The backspace (#) and delete (EOM) 
codes may be used before the New Line is typed to correct 
a mistyped key-in. The analysis and subsequent action from 
the unsolicited key-in is performed at the RBM Control Task 
priority level. Each key-in mnemonic must be followed by 
a space before its argument list. 

Specific key-in responses under RBM are: 

BL oplb = dfn[,P] Permits change of operational label 

assignments during running of background programs. 



where 



P is an optional permanent change until system 

reboot. 



BLoplb=oplb[,P] 

oplb=dfn[,Pj. 



Alternate version of BL 



BR[dt]nn Release the specified device for background 

use. The characters representing the device type are 
optional but, if input, will be used to validate the request. 

C: tcb[,C0de] Connect the specified real-time fore- 

ground task to the dedicated interrupt location. 

where 

tcb is the address of the task control block for this 

task. (If the value is hexadecimal, it must be 
shown as +xxxx.) If the Overlay Loader initializes 
the TCB by means of the tcb parameters, it does 
so completely, using load information and values 
on the TCB and BLOCK cards. No partial initiali- 
zation of a TCB is allowed with the exception of 
the blocking buffer pool. If a user builds his own 
TCB, the TCB must begin at the execution loca- 
tion plus the "temp" value specified on the 
Loader !$ROOT command. 

code if present, overrides the initial code in the 
TCB for the task; a code of 7 would cause the 
level to be triggered. If code is not present, it 
will be derived from the task control block. 



CC 



Remove the keyboard/printer override of the CC 
device. The next control command will be read from the 
background operational label CC. This operator key-in is 
identical to the CC control command. 

CP Clear card punch and simulate an unusual end con- 
dition in the punch. The key-in is required if the card punch 
fails to recover after a JAM A or JAM B. Operator should 
first manually clear the punch and restore it to READY, then 
interrupt and key in CP. The last (faulty) card will be re- 
punched and cards in the normal stacker will be in the 
correct sequence. 



DB t xxxx,yyyy 



Dump locations xxxx to yyyy if re- 



quested; otherwise, immediately dump all of background 
memory On background device DO. This key-in can be in- 
put at any time for debugging purposes. The dump will be 
in hexadecimal. 



DE 

re 



E Causes Debug (if Debug is part of the system) to 
(quest the input from the keyboard/printer. 



oplb is an assigned operational label or FORTRAN 
device unit number. 



SYSGEN options (response to INC MISC query). 
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DF^XXX.yyyy Dump locations xxxx to yyyy if re- 

quested; otherwise, dump all of foreground on background 
device DO. The dump will be in hexadecimal. 

DM XXXX,yyyy Dump locations xxxx to yyyy if re- 

quested; otherwise, immediately dump all of RBM on back- 
ground device DO. The dump will be in hexadecimal. 

D[t] mm/dd[/yy[,hrmn]] Reset the calendar date within 

RBM and continue processing if the Monitor is in an idle 
or wait state. 

D[T] mm,dd[,yy[,hr,mn]] Alternate version of 

D[T]mm/dd /yy[,hrmn] . 

DR f [dn] XXXX, yyyy Perform aselective dumpoftheRAD 

device dn to background device DO, where xxxx and yyyy 
are the first and last sectors of the block of sectors to be 
dumped. If dn is omitted, the RAD containing the SP area 
will be dumped. If dn refers to an undefined or non-RAD 
device, an error message will be written. If a consecutive 
series of sectors are all zeros, they will be skipped unless 
the last sector of this zero series is yyyy, in which case it 
will be dumped. For example, if "DR 100,200" is keyed 
in, and sectors X'lBO' through 'X'215 1 contain zeros, X'100' 
through X'ICF 1 and sector X'200 1 will be dumped. This 
key-in applies only to the 7202, 7203, and 7204 RADs. 

The RAD dump routine performs RAD input with interrupts 
inhibited, and therefore should not be used when response 
time is critical. 



If the file is aRADfile, the following additional information 
will be output: 

• Contents of the specified I/O Control Sub-table. 

• Contents of the blocking buffer assigned to the speci- 
fied file, if one exists. 



FG[,SJ Must precede any job stack operation affecting 

the foreground or the operation will be aborted. This 
key-in is effective until the next !FIN or !JOB command 
is encountered. Since the key-in is normally input in 
response to a ! PAUSE command, the optional S key-in will 
clear the idle state. 

FL oplb=dfn[,Pj Permits foreground operational label 

assignment changes during system operation. The changes 
will be reset to SYSGEN values upon system reboot. 



/her 



oplb is an assigned operational label or FORTRAN 

device unit number. 

dfn is a decimal number specifying a legal device 

file number. 

P is an optional permanent change until system reboot. 



FLoplb=oplb[,P] 



Alternate version of FL oplb = dfn[,P] 



oplb[,F] 
fdvn 
Ldfn 

/here 



Dump the information shown below for 
the specified file. 



oplb is an operational label that specifies the 

Device File Number to dump. F indicates a fore- 
ground operational label. 

fdun is a FORTRAN Device Unit Number that spec- 

ifies a DFN. F indicates a foreground fdun. 

dfn is the Device File Number to dump. 

If no parameter is specified, only the operational label 
tables will be displayed. 

When a Device File Number is specified, the following 
additional information will be output on background DO 
device: 

• Contents of the specified Device Channel Status Tables. 

• Contents of the specified File Control Tables. 

• Contents of the specified I/O Control Tables. 



FR [df]nn Reserve the specified device for foreground 

use. The characters representing the device type are op- 
tional but, if input, will be used to validate the request. 
The device type will be required to distinguish PT40 from 
KP40, etc. 

H Input hexadecimal corrector cards from background 

device CC (See Appendix G for the format of the cor- 
rector cards. ) To patch program segments, DATA switch 
must be placed in the "1" state. This causes RBM to type 
! IBEGIN SEG xx, where xx is the segment number (xx 
equals zero for the root), and go into an idle state after 
each segment is loaded. Correctors can then be loaded to 
the segment following an H key-in. An S key-in will cause 
RBM to resume operation. Correctors modifying foreground 
must be preceded by an FG key-in. 

KP Begin reading control commands from the keyboard/ 
printer. The key-in goes into effect after the next ! !CCI 
message and stays in effect until a CC key-in or !CC control 
command is encountered. 

Mdn[,[vsn][,ari,ar2 ar n ]] Mount areas "ar" on 

device ''dn". The operator must mount the disk pack con- 
taining areas "ar. " on device "dn" before making this key- 
in. Unless the area specified is Xn, the disk pack will be 



SYSGEN options (response to INC MISC query). 



SYSGEN options (response to INC MISC query). 
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read to ensure that it contains the specified areas. If no 
areas are specified, then all areas on the disk pack will be 
added to the Master Directory in core, otherwise, only the 
areas specified will be added to the Master Directory. If 
the Master Directory already contains an entry for an area, 
an error message ! I KEY ERROR, IN USE will be output. The 
currently mounted area must be removed with an R (remove) 
key-in and the M (mount) key-in reissued. Other error 
messages are listed in Table 6. The optional vsn parameter 
is a three- to eight-character volume serial number. 

Q name Queue specified program for subsequent exe- 

cution in nonresident foreground. As soon as this space is 
free, the requested program is loaded. If the queue stack 
is full or if the specified program is not found in the direc- 
tory, an error message is output on the assigned foreground 
oplb, DO. 

R [dn][,arj,ar2,.">arn] Remove areas from the Master 

Directory. If no areas "ar. " are listed, all areas on the 
device will be removed from the Master Directory. If no 
device name is listed, all of the areas listed will be re- 
moved, however, area SP may not be removed. If any files 
are in use within the areas, removal does not occur and a 
! ! KEY ERROR, IN USE message is output. An X (abort) 
key-in to abort a background program or an UL (force) key- 
in to unload a foreground program may overcome an IN USE 
situation for removal. 

S Continue processing if Monitor is in an idle or wait 
state. If there is a waiting background program, continue 
processing that program. If there is no background program, 
begin reading control cards from the CC device. (Monitor 



can get into the wait state from a W key-in or ! PAUSE com- 
mand or into idle from a !FIN command.) 

SY[,S] Permit modification of system files on the RAD 

to take place until the next !JOB or !FIN command is en- 
countered. This key-in is a double check (similar to the 
FG key-in) to prevent accidental destruction of the RAD 
files. Since this key-in is normally input in response to a 
! PAUSE command, the optional S will clear the idle state. 

T hrmm Reset the RBM system time, hour and minutes. | 



T hr,mn 



Alternate version of T hrmn. 



UL Force an unload of the program occupying the non- 
resident foreground area. Note that operator key-ins can 
interrupt the background program at any time. Operator 
intervention cannot take place while there are active fore- 
ground programs, and will be delayed until they terminate. 

W Background goes into a wait state. 

X Abort the background job with any dumps requested, 

and output error code OP and a printed message showing 
the location of last background instruction executed. If 
the Postmortem Dump program is already active, it will be 
terminated. 

Z Terminate the current background fob including the 
Postmortem Dump program without performing postmortem 
dumps (abort code ER is output). 
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4. MONITOR SERVICE ROUTINES 



BRANCHING TO SERVICE ROUTINES 

Under RBM, foreground and background programs may make 
calls on the Monitor to perform various services or privi- 
leged operations. (See Table 7.) For background requests, 
a branch to protected memory will trigger the protection 
routine which examines the branch for validity. If the 
protection violation is one of a permissible set of "con- 
trolled" violations, the branch is permitted; otherwise, the 
background job is aborted with a suitable error message 
giving the location to which the branch was attempted. If 
the branch is valid, the protection routine will permit the 
branch to the appropriate Monitor service routine. 



Actually, portions of the above routines are resident. The 
resident portion of M:CLOSE, for example, is as follows: 



M:CLOSE 



where 



RCPYI 



DATA 



P,T 

Q:ROC 
'ID NN' 



ID represents the segment identifier of the non- 
resident overlay section of M:CLOSE. 



All service routines are completely reentrant. Hence, they 
can be used by multiple tasks on a completely independent 
basis. Table 7 shows the routines requiring temporary space 
in the user's temp stack. 



There are two different methods of executing a branch to 
one of these Monitor service routines: the conventional 
method is to declare the service routine name as an ex- 
ternal reference and have the Overlay Loader satisfy the 
reference at load time. (In this case, the address lit- 
eral will be in the user's program, and will be filled in 
by the Overlay Loader.) The other method is to branch 
indirectly through the address literal in the zero table 
(see Appendix B) using the absolute address given in 
Table 7. This is a useful technique for an absolute fore- 
ground program assembly, or for a processor or other pro- 
grams that are self-relocating. 



NN 



is the temp stack requirement. 



Q:ROC will call M:RES to reserve the appropritate amount 
of temp space, will read in the required segment, and will 
transfer control to the overlay routine which runs and re- 
turns to Q:ROC. Q:ROC will reload the overlay area if 
appropriate and will then release the temp space and re- 
turn to the caller by a call to the Monitor service routine 
M:POP. Particular attention should be given to the maxi- 
mum temporary stack requirements of these routines. 



SERVICE ROUTINES 



The B register is always saved and restored since it is used 
to point to temporary space. All other registers are volatile. 
The return address (specified by the L, T, or A register) 
must point to the background area if the routine is called 
(branched to) from the background. Otherwise, a protec- 
tion violation abort occurs. 



Certain Monitor service routines are nonresident overlay 
routines. The Monitor subroutine Q:ROC controls the load- 
ing of the RBM overlay area. The following Monitor service 
routines are nonresident overlay routines: 



M:I0EX 



(General I/O Driver) 



M:ASSIGN 

M:CLOSE 

M:COC 

M:CTRL 

M:DATIME 

M:DEFINE 



M:DOW 

M:LOAD 

M:OPEN 

M:RSVP 

M:WAIT 



M:IOEX provides direct control by background programs, 
the Monitor, or foreground real-time programs over all 
I/O operations on the buffered I/O channels for centraliza- 
tion of I/O interrupts. All M:lOEX control functions are 
exempt from channel time limits. The calling sequence is 



LDX 

RCPYI 

B 



ADRLST 

P,L 

M:IOEX 



ADRLST is a pointer to the argument list, which is a set 
of two, three, or four consecutive words in the user's 



If the overlay area was originally occupied by an active 
Monitor service routine, the routine must be reloaded. If 
the requested routine is the one occupying the overlay area, 
no loading will be required. 
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Table 7. Transfer Vector for Monitor Services 



Address 


ADRL for 


Purpose of This Routine 


Words of Temp Required 


Dec. 


Hex. 


Min. 


Max. 


199 


C7 


M:FSAVE 


M:SAVE Function if all registers previously Saved 








200 


C8 


M:IOEX 


Device-Dependent I/O Driver 


16 


16 


201 


C9 


MrREAD 


Device-Independent Read Routine 


19 


51 


202 


CA 


M:WRITE 


Device-Independent Write Routine 


19 


51 


203 


CB 


M:CTRL* 


Device-Independent Control Routine 


35 


49 


204 


CC 


M:DATIME* 


Calendar Date and Time of Day 


37 


37 


205 


CD 


MrTERM 


Norma i Termination of Background 


U 





206 


CE 


MrABORT 


Abnormal Termination of Background 








207 


CF 


M:SAVE 


Save Registers on Real-Time Interrupt 








208 


DO 


M.-EXIT 


Restore Registers on Foreground Exit 








209 


Dl 


M:HEXIN 


Hexadecimal to Integer Conversion 








210 


D2 


M : INHEX 


Integer to Hexadecimal Conversion 


-0 





211 


D3 


M : CKREST 


Checkpoint/Restart Background 





65 


2T2 


D4 


MiLOAD* 


Load Nonresident Foreground 


32 


32 


213 


D5 


MrOPEN 1 


Open Blocking Buffer for RAD File 


32 


32 


214 


D6 


M:CLOSE f 


Close Blocking Buffer for RAD File 


33 


33 


215 


D7 


M.-DKEYS 


Read Data Keys 








216 


D8 


M:WAIT f 


Execute Wait Loop From Background 


34 


66 


217 


D9 


MrSEGLD 


Load Overlay Segment 


29 


61 


218 


DA 


MiDEFINE 1 " 


Define RAD Files in Background Temp Area 


32 


32 


219 


DB 


MrASSIGN 1 " 


Assign Operational Labels 


37 


51 


220 


DC 


M:POP 


Release Dynamic Temp Space 








221 


DD 


MrRES 


Reserve Dynamic Temp Space 








222 


DE 


M.-OPFILE 


Convert Operational Label to Device-File Number 








223 


DF 


MrRSVP* 


Reserve or Release Peripherals 


39 


71 


224 


E0 


M:DOW t 


Diagnostic Output Routine 


32 


64 


225 


El 


M:COC* 


Communications Handler 


44 


44 


These 


routines are nonresident RBM overlays. All nonresident RBM overlays require a minimum 


of 32 temp cells to load 


the ro 


utine. 




Notes 


: 1. To branch to one of these routines, branch indirectly through the specified address 
(except M.-RES which is called following an RCPYI P,T). 


above after RCPYI P,L 




2. The minimum temp space required is the number used by the routine itself. The maximum temp space is the 
number required by this routine and those it calls, plus 19 if any of the routines are nonresident RBM over- 
lays. For example, MrREAD (19) may call Q:ROC to load MrOPEN (13) and Q:ROC will reenter 
MrREAD (19) to load the overlay. A total of 51 temp cells will be used. 




3. MrWRITE calls MrCLOSE when it receives a "write-end-of-f?le" command for 1 


?AD files. This requires 




51 temp cells. 
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Table 7. Transfer Vector for Monitor Services (cont. ) 



Notes: 4. 
(cont. ) 

5. 



6. 



Normally, MrSEGLD requires 29 temp cells. However, 61 are required to output the message ! ! BEGIN 
SEG xx. This is an RBM assembly option (i.e., Debug = yes). 

MrCKREST requires 65 temp cells if the checkpoint is performed at the priority level of the calling task 
and the message ! !BKG CKPT is to be typed out. This message can be suppressed if bit 8 of RrSYFG is 
set, in which case MrCKREST requires 33 temp cells. 

Use of any device that has a nonresident device dependent I/O edit or error recovery routine associated 
with it requires 51 temp cells by M:READ/M:WRITE. These include KP, PT, LP, B7, CR, andCP. However, 
if one of these devices is not ready, 83 temp cells may be required. 



program or in a temporary stack. This argument list appears 
as follows: 

word 



word 3 



F 


A 


Z 





OP 



1 

where 
F 



OP 



word 1 



12 13 



15 



word 2 



= if word 1 is an operational label or device 
unit number. 

= 1 if word 1 is a device file number. 

= 1 if AIO Receiver is specified in word 3 (fore- 
ground option only). 

= is no AIO Receiver is specified (three-word 
call, then). 

= 1 if AIO Receiver is acknowledged on zero 
byte count interrupt. 

= if acknowledged on channel end only. 

is the code for the operation to be performed: 

for SIO 

1 for TIO 

2 for TDV 

3 for HIO 

4 for "check previous data transfer" 



Operational label or file number 



15 



Address of first IOCD (for SIO only) 



Address of AIO Receiver (for SIO only) 







15 



15 



Return is to the location in the L register on the call to 
M:IOEX. B register is always saved. 

The Overflow (OI) and Carry (CI) Indicators, the A register, 
E register, and (in some cases) X register are used to return 
status information on the required operation. The complete 
list of status codes is given in Table 8. In this table, DSB 
stands for Device Status Byte, OSB for Operational Status 
Byte, Byte Count Residue is from the even I/O channel 
register at channel end, and Dev. No. stands for the de- 
vice number of the current device. 

Note that no I/O error recovery has been attempted. DSBs 
and OSBs are fust as received from the I/O system hardware. 
These status returns are organized so that a quick and simple 
test will show the nature of the return. If the user wishes 
to keep trying to initiate the I/O operation or keep check- 
ing for completion, it is possible to loop back to the call 
to M:IOEX. 

The user can use M:IOEX to read/write on the RAD or 
any peripheral device that uses standard Xerox Sigma pe- 
ripheral responses. For input/output operations to the 
RAD, the user must first give a seek order and then the 
appropriate data-transfer request. The user must also per- 
form his own file management. If multiple tasks use the 
RAD, they must cooperate in some way so that the seek 
address is not modified by some higher-level task before the 
data operation is initiated. Note that a user must always 
issue a "Check" (op code of 4) after each read or write 
request. 

The following rules govern the use of M-.IOEX for a RAD: 

1. A device-file name of the form XXdn must be included 
in the set of SYSGEN input parameters following the 
heading DEVICE FILE INFO, where XX indicates that 
this is a special -purpose device for use with MrlOEX, 
and dn is the hardware device number of the RAD. The 
M:IOEX calling sequence must contain the device-file 
number corresponding to this device-file name, or must 
contain an operational label that is assigned to the 
device-file number. 
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Table 8. Return Status from M-.IOEX 



Operation 


Major Status 


OI 


CI 


E Register 


A Register 


X Register 





1 -7 


8-15 


0-7 


8-15 


0-15 


SIO, TIO, 
TDV, HIO 


Device number 
not recognized 


1 


1 







Recognition Code 







All 


Invalid call or oplb 








1 




4 or 8 







oplb equals zero 













2 







SIO 


SIO cannot be 
accepted 





] 





Current file 
Number 


TIO 


uev. ino. 


A 


Channel busy 











Active file 
Number 


DSB 


Dev. No. 


-1 


Successful 
initiation 











Current file 
Number 


SIO 
DSB 


Dev. No. 





TIO 


SIO cannot be . 
accepted 





1 





Current file 
Number 


TIO 
DSB 


Dev. No. 






Other 











TDV 


Device abnormal 
condition 





1 





Current file 
Number 


TDV 
DSB 


Dev. No. 




Device normal 
condition 













HIO 


Device operating 
when HIO 
received 





1 





Current file 
Number 


HIO 
DSB 


Dev. No. 




Device not oper- 
ating when HIO 
received 













I/O check 


I/O operation 
in progress 


1 








Current file 
Number 


SIO 
DSB 


Dev. No. 






I/O completed 
unusual end 





1 





E 

Flag 
(Bit 7) 


OSB 


AIO 
DSB 


Dev. No. 


Byte Count 
Residue 


I/O completed 
normal end 











Use BXNC to test both conditions simultaneously. 


Legend: 

DSB = Device Status Byte 

OBS = Operational Status Byte 
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The set of SYSGEN input parameters following the 
heading RAD ALLOCATION must include provisions 
for reserved tracks that are not to be included in the 
areas allocated for RBM file management. This can be 
accomplished by 

a. Assigning the system RAD to a device number other 
than XXdn. This method requires two RADs, one 
containing the RBM area assignments, and the 
other available for use with M:lOEX. 



Allocating only part of a RAD for RBM area assign- 
ments, leaving the remainder available for use 
with M:IOEX. 

Allocating part of a RAD forM:IOEXuse by speci- 
fying that a number of tracks be skipped between 
RBM areas with an allocation parameter of SK = n, 
where n is the number of tracks. 



d. Any meaningful combination of the above. 



M:IOEX FUNCTIONS 



TIO, TDV, HIO In these operations, the request is per- 

formed immediately and the device status bytes are returned 
if the device is recognized. The AIO Receiver is ineffec- 
tive for these operations. 



SIO The SIO operation is initiated if there is device 

recognition and the channel is free (which may not be the 
same as "device free" or "device controller free" for chan- 
nels with several devices). 

The SIO is issued even if the device is in the manual mode. 
It is therefore the responsibility of the user's program to test 
for the manual mode both before and after the SIO request, 
and to inform the operator by a suitable message. 

An HIO can be used to abort an I/O operation. This results 
in setting the channel end device ready for a new activity. 
Since status is returned, an I/O check operation is not 
returned. 

Protection checks are performed only for background I/O 
requests. Background is not permitted an AIO Receiver, 
and a receiver is ignored if requested from the background. 
Background operations specifying data chaining are not 
allocated. This is due to the structure of the IOCDs, I/O 
Data Tables, and the requirements for the absolute protec- 
tion of foreground programs (see "End Action" in Chapter 5). 

If the request for I/O action is for an odd number of bytes, 
the order byte must be properly set in the right half of the 
word, as specified in the Sigma 2 and Sigma 3 Computer 
Reference Manuals. M:IOEX does not move any data or 
order bytes. 



When using foreground data chaining, it is very important 
to set the interrupt flags on all IOCDs except for the one 
pointing to the "order" byte, since an unusual end condi- 
tion in one of the IOCDs without the interrupt flag being 
set will cause the I/O to terminate without an interrupt, 
and the channel may then "hang up" waiting for the in- 
terrupt because the RBM tables indicate that the channel 
is still busy. 

The Monitor does not alter the user's data in any way. If 
an I/O interrupt is received and there is no AIO Receiver 
specified (and the device is still busy), the I/O interrupt 
is ignored and the channel remains active. 

The user's program must determine whether there was a 
channel end or an unusual end condition. If the return is 
for a busy device or channel, the program can loop on this 
request until the operation is successful. 

Since only higher priority tasks can take control from the 
task issuing the request, the routine issuing the request 
gains control of the desired device and/or channel as soon 
as the current operation is complete. The M:IOEX routine 
inhibits interrupts for a period of less than 100 microseconds 
during the loading of the I/O channel registers and the set- 
ting of the activity status for the device and channel. Thus 
a higher priority task can always interrupt up to the point 
when the I/O channels are loaded during the initiation of 
an I/O request. 



I/O CHECK This operation tests for channel end on the 

previously requested I/O operation by testing certain flags 
within the RBM I/O tables. The flag is set by the I/O 
interrupt task when the device interrupt occurs. Thus, 
no TIOs are required to determine when the operation is 
complete. Since the TIOs do consume some I/O time 
(particularly if executed repeatedly in a test loop), the 
method of checking for I/O completion described herein 
is desirable. The Monitor saves the operational status 
byte and the byte count residue from the completion of 
the I/O operation, even though another device may have 
used the channel before the end-action check is made by 
the requesting task. 

The following restrictions are pertinent in using M:IOEX: 

1. RBM will not necessarily recover automatically from 
the results of an HIO for most devices. Operator in- 
tervention may be necessary. 

2. Background programs cannot specify data chaining. 

3. Background programs must specify an interrupt. 



MlREAD (General Read Routine) 

M:READ provides device-independent input with stan- 
dard editing and checking. Standard error detection and 
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correction is optional on each call, 
quence is 



The calling se- 



LDX 
RCPYI 



ADRLST 

P,L 

MrREAD 



ADRLST is a pointer to the argument list, a set of two to 
six words in the user's program or in a temporary stack. 
This argument list appears as: 

word 



F 


A 


W 


E 


R 


| ORDER 



1 2 3 4 5 



7 8 



15 



F = 1 if a device-file number is specified. 

= if an operational label or device unit num- 
ber is specified. 

A = 1 if an AIO Receiver address is specified 

(specificable by foreground only). 

= if no AIO Receiver is specified. 

W = 1 if wait for completion is unconditional. 

= if wait is for "initiate and return" only; 
return is immediate if operation cannot be 
started at once. (The minimum-seek algo- 
rithm does not apply to RAD "no wait" 
operations.) 

E = 1 if standard error recovery is to be performed 

at channel end. 

= if no error recovery is to be attempted. 

For magnetic tapes, RAD, or disk pack, five attempts 
for error recovery will be made if E is specified. If 
I/O without a WAIT is specified, error recovery will 
not be performed until A "Check" is issued by the user. 
See RAD and Disk Pack Error Recovery 

R = 1 if a RAD record displacement is specified 

(granule or logical record number, applic- 
able only to random files). If the file is not 
random, calling sequence error is returned. 

= if a RAD record displacement is not specified 
and implies sequential access of random files 
or sequential files. 



ORDER is one of the following permissible pseudo 

input orders: 

Order Operation 

X'OO' Return information about this device 

and file. See Return Registers. 

X'02' Read binary. 

X'04' Check previous input for completion 

(after a "no wait" initiation). 

X'06' Read automatic. 

X'OC Read backward (9- track magnetic 

tape omy;. 

X'10' Return information on FORTRAN 

associated files. 



>rd 1 



Operational label or file number 




word 2 



15 



Address of buffer to receive data 







15 



Buffer must be in background if called by a background 
program. Also, buffer must not overlap active temporary 
storage or unavailable memory. 

word 3 



Number of bytes to transmit 







15 



Byte count must be an even number when reading from RAD 
files and cannot exceed 65,536. For all other devices the 
byte count may be either even or odd but cannot exceed 
8192. If the byte count is even, input data stored in the 
user's buffer starts in the left-hand byte; if odd, data starts 
in the right-hand byte. 

word 4 



AIO Receiver or RAD record displacement 



15 



If A = 1 (in word 0), this is the address of the closed AIO 
Receiver subroutine called by the I/O interrupt task at 
channel end. If A = 0, this is the RAD record displacement 
(granule or logical record). 
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word 5 



RAD record displacement (optional) 



15 



If an AIO address is specified (A = 1 in word 0), word 5 
Indicates the displacement from the start of the file (starting 
with a displacement of zero). Transfer starts at the begin- 
ning of the indicated file unit. Word 4 is RAD file unit 
displacement if A = 0. 

While blocked and unblocked random files may be accessed 
randomly or sequentially, the usage modes should not be 
freely mixed. Note that if the R bit is not set for random 
files, the file is processed sequentially. 



is a calling sequence error, in which case the E register is 
negative upon return. For the case where a wait is speci- 
fied, the I/O is initiated and the MrREAD routine loops 
until the operation is complete. When "initiate and no- 
wait" is specified, an SIO is issued before the return if the 
device is recognized, is currently free, can accept an SIO, 
and is not in the "manual" mode (unless M = 1 in word 0). 
If any one of these conditions is false,, the M:READ routine 
returns immediately with the appropriate indicators set. If 
the channel or device is busy, the caller can either loop 
back to the call to MrREAD or switch to another device. 
The "wait" flag has meaning whether this is an initiate or 
a check order. Error recovery is attempted if specified 
before the final return is made. 

On a check operation, the byte count returned in the X 
register may not be meaningful if the calling sequence does 
not specify the same count as the initial read. If the order 
code is X'OO', the following device status information is 
returned: 



RETURN REGISTERS 

Return is always to the location specified in the L register. 
The B register is always saved. 

The E, A, and X registers all contain status information on 
the return, as shown in Table 9. I/O completion codes 
are listed in Table 10. Return is always immediate if there 



Register Status Information 



Device name (EBCDIC). 

TDV device status byte (bits 0-7) and physi- 
cal device number (bits 8-15). 

Physical standard record size (bytes fornon- 
RAD files or granule size for RAD files. 



Table 9. Return Status from MrREAD, MrWRITE, MrCTRL 



Operation 


Major Status 


Action 


EReg. 


A Reg. 


X Reg. 


All operations 


Operational labels not 
valid 


Return immediately 


-1 


8 


tt 




Calling sequence error 


Return immediately 


-1 


4 


tt 




Operational label is set 


Return immediately 





2 


t 




to zero 












RAD file positioned at 


Return immediately 





4 


t 




EOT 












Unrecoverable I/O error 


Return after error recovery 
attempt, if any 


-1 


1 


t 




Illegal sequence of RAD 


Return immediately 





9 


t 




operations 












Blocking buffer not 


Return immediately 





10 


t 




available 










Initiate I/O 


Channel and device are 


Initiate I/O and return. 








0or-l 


and no wait 


free and in automatic 


Status in X register only 








Unspecified 












sector size (in 


bytes) of the device containin 


g the BT area. 
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Table 9. Return Status from MrREAD, MrWRITE, M:CTRL (cont. ) 



_____ — _ _ — — — 

Operation 


Major Status 


Action 


EReg. 


A Reg. 


X Reg. 






meaningful if A = l in the 
call and the A register is 
zero upon return. X=-1 
if the AIO Receiver will 
not be acknowledged; 
otherwise X = 0. 










Channel and/or device 


Return immediately 





-1 


t 




are busy 












Manual intervention is 


Return immediately 


- 1 


- 1 


i. 
I 




required (manual mode 
or no device recognized 












Completion available 
without I/O being 
initiated 


Return immediately 





See Table 10 


t 


Check and 
no wait 


I/O still in progress 


Return immediately 





-1 


t 




I/O complete 


Return after end- 
action, if any 


Oor-1 


completion 
code 


Byte 
count 


Initiate and 
wait 


Channel and device are 
free and automatic 

Channel or device 
are busy 

Device number is not 
recognized or is write 
protected 

Device is in manual 
mode 


Initiate I/O and wait 
for completion 

Wait and keep trying 

Type out the proper 
message to operator 
and retry 

Type out EMPTY mes- 
sage to operator and 
retry 








Initiate and 
wait or check 
and wait 


I/O still in progress 


Wait, and keep 
checking 








I/O complete 


Perform any end- 
action and return 


Oor-1 


completion 
code 


Byte 

count 

transmitted 


t 
Unspecified 
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Table 10. I/O Completion Codes 



EReg. 


A Reg. 


Meaning 


Comment 








Operation successful. 


X register contains the number of data bytes 
transmitted. 


-1 


1 


Unrecoverable I/O. 


If error recovery was specified, the maximum number 
of retries have been unsuccessfully attempted. 





1 


Operation not meaningful for 
this device. 


Either an operational label was assigned to file zero 
or I/O operation is not meaningful for the device. 





3 f 


End-of-file encountered. 


Significant only for magnetic tape and sequential RAD 
files (except in automatic mode when significant also 
for cards, paper tape, and keyboard/printer). 





i 


End-of-tape encountered. 


Significant only for magnetic tape or sequential and 
random-access RAD files. 





5 


Incorrect record length. 


For read operations, the requested byte count does not 
equal the device's physical or logical record size. For 
write operations, the requested byte count is greater 
than the device's physical or logical record size. For 
either read or write, the actual byte count transmitted 
is returned in the X register. 





6 


No I/O pending for this check 
operation. 


Error in I/O buffering. An initial no-wait I/O request 
either was not issued or was rejected. 





i 


Device is write -protected. 


Significant only for writing on magnetic tapes and RAD 
f i les. 





8 


Beginning-of-tape encountered. 


Significant only for reading backward and for position- 
ing magnetic tapes and sequential RAD files via 
M:CTRL. 





9 


Illegal sequence of RAD 
operations. 


Significant only for sequential RAD files. 





!0 t 


Blocking buffer unavailable. 


Significant only for blocked or compressed sequential 
RAD files. 


Status also meaningful under initiate I/O and no wait. 



If the code is X'10', the following status information is 
returned for random or packed files: 

Register Status Information 

A Address of the FORTRAN associated vari- 

able (PTR). 



File units per FORTRAN logical record. 

File unit in bytes (granule or logical 
record size). 



If a read is attempted to a flawed track in disk pack files, 
the header of the flawed track is read to determine its 



alternate. The alternate track is then read as if it were 
the original. 



MrREAD FUNCTIONS 

MrREAD is designed to read one physical record from the 
specified device regardless of device type and whether the 
record is EBCDIC or binary. Therefore, MrREAD will set 
up the proper order bytes for the actual device, using the 
"pseudo order byte" given in the call to MrREAD only as 
a guide. The user may request fewer bytes than are in the 
record and only this number will be returned in his buffer. 
However, if more bytes are requested than are in the 
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record, only the bytes in the record will be read. In 
any case, the actual number of bytes read will be re- 
turned in the X register when the completion code is re- 
turned, and if this is not the same as the number of bytes 
requested, an "incorrect length" code will be returned. 
While it is not always necessary for the user to check all 
possible return codes, it may be useful to print them out to 
aid in debugging. 

If an attempt to read a record from magnetic tape results in 
the detection of an irrecoverable transmission error and 
incorrect length condition, and if fewer than eight bytes 
were read from tape, it will be skipped and the next record 
on tape will be read. 

Using MrREAD, a user can read 80 EBCDIC bytes regardless 
of whether they come from cards,. DaDer tape, magnetic 
tape, keyboard/printer, or RAD. MrREAD will perform 
standard editing from paper tape to give a record a format 
identical to card image output. 

By using a "read and no wait" followed later by a "check 
for input complete" the user can effectively overlap input 
and compute. 

The order code X'00 1 is used to request information about 
an unknown device, and may be helpful in determining the 
optimum blocking sizes to use. 



REAL-TIME PRIORITY 

All of the I/O routines are reentrant, and any input can be 
interrupted for a higher-priority task up to the "point of no 
return" of setting Monitor status flags and loading channel 
registers. External and internal interrupts are inhibited for 
up to 100 microseconds of CPU time during the actual SIO 
sequence. Keeping a high priority task active and looping 
on an input request to a busy device enables the task to 
seize control of the channel or device as soon as the cur- 
rent I/O operation completes. 



SPECIAL EDITING FOR CARD READER 

Read Automatic. Any cards with a "1" and "2" punch in 
column 1 are automatically read as binary; all other cards 
are read as EBCDIC or BCD. (For nonstandard binary cards, 
the user must use "read binary".) It is possible to specify 
that all cards from a certain file are to be read as BCD and 
converted by the MrREAD routine to EBCDIC before being 
returned to the user. Since this would apply only to one 
file, it is possible to read some cards in EBCDIC and some 
in BCD from the card reader. (BCD card codes are pro- 
duced by an IBM 026 keypunch, and EBCDIC card codes 
are produced by an IBM 029 keypunch. ) The EBCDIC 
record size is 80, and the binary record size is 120 bytes. 



An incorrect length status is returned if the requested byte 
count does not exactly match. An "end-of-file" status is 
returned when an EBCDIC card that begins with !EOD is 
input into the user's buffer. An "end-of-tape" status is 
never returned. 



Read Binary. An "incorrect length" status is returned if 
the requested byte count does not equal the maximum num- 
ber of bytes requested in the calling sequence. The num- 
ber of bytes requested, up to a maximum of 120, are input 
in the user's buffer. "End-of-file" and "end-of-tape" status 
codes are never returned. 



SPECIAL EDITING FOR PAPER TAPE OR KEYBOARD/ 
PRINTER 



Read Automatic. All input from paper tape or keyboard/ 
printer is initiated in a one-byte-at-a-time mode. From 
paper tape, the read order is always "read ignoring leader". 
If the first byte is a code of X'lC, X'3C*, X'FF', X'9F', 
X'BF', X'DF', or X'78' (which can only happen with paper 
tape), the MrREAD routine switches to a binary mode and 
reads up to 119 more bytes (for a total of 120 in the record). 
The code byte will be the first byte in the user's buffer. 

Code bytes are all invalid EBCDIC codes in the sense that 
they are not printable graphics or control codes. Since 
they are all supersets of the card reader "1 and 2 punch" 
rule for column one, the same codes for "read automatic" 
can be used for the card reader as for paper tape and, in 
both cases, the code is part of the user's data buffer. If 
the first byte from the paper tape or keyboard/printer is not 
one of the binary codes MrREAD continues to read one byte 
at a time until a NEW LINE code is encountered. 

When a NEW LINE code is encountered, input transmission 
is terminated and the line image is filled out with blanks 
to the requested byte count. The NEW LINE code is not 
transmitted to the user's buffer, (if a NEW LINE code is 
the first code in the input line, it is ignored.) 

Thus, all EBCDIC records are of variable length, up to the 
maximum requested or until a NEW LINE is encountered. 
Further, EOM and cent (^) have special meanings within 
the user's data line. An EOM causes the entire line up to 
the present position (including the EOM byte) to be dis- 
carded. A ^ sign acts like a backspace. For each £ sign 
received, this byte and the byte preceding it are thrown 
away. 

When reading binary records in the automatic mode, 120 bytes 
are read regardless of the number of bytes requested. For 
EBCDIC records, the paper tape is read up to and including 
the NEW LINE code. For either EBCDIC or binary records, 
not more than the maximum number of bytes requested is 
transmitted to the user's buffer. The requested byte count 
must be 80 for EBCDIC records and 120 for binary records. 
Any other byte counts result in an "incorrect length" 
status return- 
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An "end-of-file" status is returned when an EBCDIC record 
that begins with !EOD is input into the user's buffer. 

Read Binary From Paper Tape. The Read Binary order for 
paper tape is "read immediate" by a SYSGEN PA option. 
The physical record size is the number of bytes requested by 
the user's input. The next record starts immediately follow- 
ing the last byte of the previous record and the requested 
byte count determines the end-of-record. "Incorrect length" 
and "end-of-file" status codes are never returned. "End- 
of-tape" status is not returned, even when the paper tape 
runs off the reader. 

Read Binary From Keyboard/Printer. A read binary order 
causes the keyboard/printer to read the exact number of 
bytes specified. RBM performs no editing, and no bytes 
(including NEWLINE codes) are considered control bytes. 
"Incorrect length", "end-of-tape", and "end-of-file" 
status codes are never returned. 



SPECIAL EDITING FOR MAGNETIC TAPE 



MrOPEN to reserve a buffer from the calling task's buffer 
pool. If no buffer is available, M:READ exits with a 
"blocking buffer unavailable" status. 

Compressed records are decompressed by MrREAD so that 
only the expanded record, without compression codes, is 
input into the user's buffer. 

A byte count can be requested that is less than, equal to, 
or greater than the file's logical record size. The number 
of bytes requested, up to a maximum of the logical record 
size, is always transferred. If the byte count does not equal 
the logical record size, "incorrect length" status is returned. 
In any case, the file is positioned to the next logical record, 
regardless of the byte count transferred. For compressed 
files, the requested byte count is compared to the byte 
count of the expanded record instead of the logical record 
size. "End-of-file" status is returned when the file is 
positioned at the logical EOF. "End-of-tape" status is 
returned when the file is positioned at the logical EOT. 
This is true whether or not error recovery is specified. 

A Read Backward order will be interpreted as a Read order. 



Read EBCDIC or binary. Binary and EBCDIC modes are 
identical on 9-track tape, and MrREAD supports only the 
BCD and packed-binary modes* for 7-track tapes. Only the 
number of bytes requested is transferred to the user's buffer 
regardless of the physical record. "Incorrect length" status 
is returned when there are either too few or too many bytes 
in the input record, and the tape is positioned at the start 
of the next physical record. "Incorrect length" will not be 
reported for too many bytes in the input record for 7-track, 
packed binary tapes. 



"End-of-file" status is returned when a file mark is sensed 
on the magnetic tape; "end-of-tape" status, when the phys- 
ical end-of-tape mark is sensed and standard error recovery 
is specified. If both are sensed at the same time, the "end- 
of-tape" status is returned. 

The Read Backward order produces a buffer with data in an 
inverted condition. If the tape is at the load point when 
the Read Backward order is given, no data is transmitted 
and "BOT" status is returned. Read Backward will be 
ignored for devices other than 9-track magnetic tape. 

SPECIAL EDITING FOR SEQUENTIAL RAD FILES 

Read Automatic or Binary. On a RAD, binary and EBCDIC 
modes are identical. When reading from blocked files, a 
blocking buffer must be supplied. If the calling program 
has not specified a blocking buffer, M:READ will call 



SPECIAL EDITING FOR RANDOM-ACCESS RAD FILES 

Read Automatic or Binary. Binary and EBCDIC modes are 
again identical. For unblocked random files, the exact 
number of bytes requested will be put into the user's buffer 
and "incorrect length" status will not be returned. One or 
more granules will be read to satisfy the byte count. RAD 
space between granules is lost. Unused parts of granules 
are ignored. 

For blocked random files, no more than one record will be 
transferred. A greater byte count request results in incor- 
rect length. The file will always be positioned at the next 
record after a successful transfer. 

If the Read begins or extends beyond the file's ending 
boundary, no data is transmitted and "end-of-tape" status 
is returned. For blocked random files, an end-of-file may 
also occur. This is true whether error recovery is specified 
or not. 

Note: For all RAD files, no transfer will be initiated that 
crosses a track boundary. Instead, it will be broken 
into two transfers: one to transfer to the end of the 
track, and a second to complete the transfer. There- 
fore, in a "no-wait" operation, a check must be 
requested to complete the transfer. If an AIO Re- 
ceiver is specified, it will be entered each time 
channel end occurs, but it also must be specified in 
each Check operation call. 



The user should be thoroughly fami I iary with the BCD and 
packed-binary mode if 7-track magnetic tape is used. See 
the 7-Track Magnetic Tape System Reference Manual, 
Publication 90 09 78). 



M:WRITE 



(General Write Routine) 



M:WRITE provides independent output with standard editing 
and standard error detection and correction. The error 
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handling procedure is optional on each call to M:WRITE. 
The calling sequence is 



LDX 



ADRLST 



RCPYI P,L 

B MrWRITE 

ADRLST is a pointer to the argument list, which is a set 
of two to six words in the user's program or in a temporary 
stack. The argument list consists of six words: 

word 



FA WE R 



ORDER 



1 2 3 4 5 



7 8 



15 



word 1 



Order Operation 



X'03' 
X'04' 

X'05' 
X'07' 
X'10' 



Write file mark or !EOD. 

Check previous output for comple- 
tion (after a "no wait" initiation). 

Write EBCDIC. 

Check write (RAD only). 

Return information on FORTRAN 
associated files. 



Operational laoei or rile numoer 



15 



F - 1 if a device-file number is specified. 

= if an operational label or device unit is 
specified. 

A = 1 if an AIO Receiver address is specified. 

= if no AIO Receiver address is specified. 

Note: only a foreground operation can specify 
this. 

W = 1 if wait for completion is unconditional. 

= if wait is only for "initiate and return"; re- 
turn is immediate if the operation cannot be 
started immediately. 

E = 1 if standard error recovery is to be performed 

at channel end for this operation. 

= if no error recovery is to be attempted. For 
magnetic tapes, RAD, or disk pack, five 
attempts for error recovery will be made if 
E is specified. If I/O without a WAIT is 
specified, error recovery will not be per- 
formed until a "Check" is issued by the user. 

R = 1 if a RAD record displacement is specified 

(can only be specified for random-access 
RAD files). 

= if a RAD record displacement is not specified. 

ORDER is one of the following pseudo order bytes: 

Order Operation 

X'OO 1 Return informationaboutthisdevice. 

X'01' Write binary. 



word 2 



Address of buffer containing data 



15 



word 3 




Number of bytes to transmit 



15 



The byte count must be an even number when writing on 
RAD files and may not exceed 65,534. It may be either 
even or odd for all other devices, but cannot exceed 
8192 bytes. If an odd byte count is requested, the first 
byte is written from the right half of the word and the left 
half is ignored. If an even byte count is requested, the 
byte is written from the left half of the first word. 

Output to the card punch assumes an even byte count. An 
extra byte at the start of the buffer is sent if the count is 
odd. 



word 4 



AIO Receiver or RAD record displacement 







15 



This is the address of the closed AIO Receiver subroutine 
called by the I/O interrupt task at the channel end, if 
A = 1 (word 0). If A = 0, this is the RAD granule displace- 
ment (granule or record) 



word 5 



-i I 



RAD record displacement (optional) 



15 
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If an AIO address is specified (A = 1 in word 0), word 5 
indicates the displacement from the start of the file (starting 
with a displacement of zero). Transfer starts at the begin- 
ning of the indicated file unit. Word 4 is the RAD file unit 
displacement if A = 0. 

Packed and unblocked random files may be accessed randomly 
or sequentially. Note that if the R— bit is not set for random 
files, the file is processed sequentially. 



Write End-of-File. Order code X'03' produces the fol- 
lowing results: 



RETURN REGISTERS 

The return is to the location in the L register. The B regis- 
ter is always saved. 

The status is returned in the E, A, and X registers. 
Status and method of returning status are the same as for 
MrREAD. 

If the code is X'10 1 , the following status information is 
returned for random or packed files: 

Register Status Information 

A Address of the FORTRAN associated vari- 

able (PTR). 



File units per FORTRAN logical record. 

File unit in bytes (granule or logical record 
size). 



If a write is attempted to a flawed track in disk pack files, 
the header of the flawed track is read to determine its alter- 
nate. The alternate track is then written as if it were the 
original. 



Device 



Result 



Line Printer No effect 

Keyboard/Printer No effect 

Card Punch !EOD card 

Paper Tape Punch !EOD NL 

Magnetic Tape EOF tape mark 

RAD Logical file mark 

For devices where the Write End-of-File order has no mean- 
ing, a status of "operation not meaningful for this device" 
will be returned. If a magnetic tape or sequential RAD 
file is positioned at the end-of-tape, the end-of-file will 
be output. (This is the only writing allowed past the end- 
of-tape when error checking is specified.) For RAD files, 
the end-of-file is set to the current record position within 
the file as determined by the last access through M:READ, 
M:WRITE, or M.-CTRL. An implicit call to M:CLOSE is 
made and any data written in the blocking buffer will be 
output to the RAD. For a random file, the R-bit may be 
explicitly used in the write EOF function to specify the 
highest numbered record plus one as the logical file mark. 
This function is useful in subsequent RAD Editor operations. 

Write EBCDIC to Keyboard/Printer. The first byte is as- 
sumed to be a carriage control byte and is never printed. 
If the byte is a zero or a one, double spacing is used; other- 
wise, single spacing is used. In any case, this first byte 
is not sent to the keyboard/printer. Trailing blanks are 
removed and a NEW LINE code is command chained to the 
last nonblank byte of the user's buffer. If there are more 
than 85 printable characters, those beyond 85 are ignored, 
and a status of "incorrect length" is returned. 



M:WRITE FUNCTIONS 

M:WRITE is designed to write one physical record on the 
device specified, regardless of the device type. Because 
of differences in Write orders for the card punch, it is 
necessary to specify whether the output record is binary or 
EBCDIC. (For most other devices, the difference is not 
meaningful. ) 

Not more than one physical record will be written for a 
single Write order. For devices like the card punch, if 
fewer than a standard number of bytes are specified (80 for 
EBCDIC and 120 for binary), the remainder of the record 
is padded with blanks (EBCDIC) or zeros (binary). Most of 
the general comments which apply to M:READ also apply 
to M:WRITE. 



Write Binary to Keyboard/Printer. The exact number of 
bytes specified is written. No format byte is assumed, no 
editing is performed, and no line format is imposed. If is 
the user's responsibility to insert NEW LINE codes if more 
than 85 bytes are output. A maximum of 256 bytes may be 
output with one operation. 

Write EBCDIC to Paper Tape. Trailing blanks are removed 
and a NEW LINE code is inserted as the last byte (if not 
already present). The entire record, specified by the byte 
count, is edited and output and an "incorrect length" status 
is never returned. 



Write Binary or EBCDIC to Line Printer. The first byte per 
record is always assumed to be a carriage control (format) 
byte, and is never printed. With any odd byte count (as in 
all of the I/O), the first byte transmitted is from the right 
half of the first word, and the left half of the first word is 
ignored. 
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The print routine changes the logical format byte (as shown 
below) to the proper physical format code for the printer. 
If more than 133 bytes are specified, the remainder beyond 
133 bytes is ignored and an "incorrect length" status re- 
turned. If fewer than 133 bytes are specified, the right 
(trailing) portion of the printed image will contain blanks. 
However, the user's buffer is not modified. The print rou- 
tine will first data chain on the order byte and format byte 
in the Monitor area and then on the user's print image. 



If it is desired to force single spacing, there may be a word 
appended to the beginning of the user buffer with a blank 
in the right half; the byte count is then increased to an odd 
value, and up to 132 bytes from the original buffer will be 
printed with the extra "blank" used as the format byte to 

fnrrp cinnlp <;nn<~inn. Th(=> fnrmrit rnrli=>? (in FRC HlCl nrp 



Write EBCDIC or Binary on Magnetic Tape. Variable- 
length records are possible; no check is made of the data 
and no editing is performed. The exact byte count (up to 
the allowable maximum) is always written, however for 
reliability reasons, it is recommended that byte counts less 
than twelve or greater than 8190 not be used. For 7-track 
magnetic tape, the data is recorded in either BCD or 
packed-binary format, which may cause an "incorrect 
length" status if the record is not read with the same byte 
count used to write the record (see the 7-Track Magnetic 
Tape System Reference Manual, Publication 90 09 78). No 
"incorrect length" status is ever returned. 

If the tape is positioned past the end-of-tape marker and 

error checking is specified, the data is not transmitted and 

"end-of-tape" status is returned. If error checking is not 
:r:__i iL_ ._i_i._ :_ ». : ti- i i ».L_ " i r_i_. " 

ipci,ii ICU, i mc UUIU 13 1 IUI I3IH I I ICU VJIIU IMC cnu _ ui _ iupc 

status is not returned. 



Format Byte Effect 



blank No space before printing, single 

space after printing. 

1 Page eject before printing, single 

space after printing. 

Single space before printing, single 

space after printing. 

No space before printing, no space 
after printing. 



Any other format code will be treated like a blank but will 
not be printed. These are standard FORTRAN format char- 
acters with the exception of the minus sign (-) which is sub- 
stituted for the standard FORTRAN plus sign (+) to allow 
overprinting. The user can use M:IOEX (Genera! I/O 
Driver) to send the standard format code or any other format 
code for XDS printers. 



Write EBCDIC to Card Punch. Regardless of the byte count 
requested, 80 bytes are always output. If fewer than 80 
bytes are requested, the punch image is filled out with 
blanks. The image is moved to a Monitor buffer; the user's 
buffer is never modified. If more than 80 bytes are re- 
quested, only the first 80 are output and the surplus is ig- 
nored. In this case, "incorrect length" status is returned. 
If the file has been declared BCD at system initialization, 
all EBCDIC output records are converted to BCD before 
being punched. (The operation is performed in the Moni- 
tor's buffer.) 



Write Binary to Card Punch. Regardless of the byte count 
requested 120 bytes are always output. If less than 
120 bytes are requested, the punch image is padded with 
trailing zeros. (The image is moved to a Monitor buffer; 
the user's buffer is never modified.) If more than 120 bytes 
are requested, only the first 120 will be output and the 
remainder ignored. In this case, an "incorrect length" 
status is returned. 



If the tape is physically write-protected and an "initiate 
no-wait" order is requested, the "write-protected" status 
is returned. If an "initiate and wait" order is requested, 
the Monitor puts out an alarm and waits for operator action 
(see the pseudo order bytes under the definition for ORDER 
under word of the argument list). 

Write EBCDIC or Binary on Sequential RAD Files. When 
writing on blocked files, a blocking buffer must be sup- 
plied. If the calling program has not specified a blocking 
buffer, M:WRITE will call M:OPEN to reserve space in the 
task's buffer pool. If no buffer is available, M:WRITE exits 
with a "blocking buffer unavailable" status. 

Records to be written on compressed files are edited with 
compression codes inserted in a Monitor buffer. The data 
in the user's buffer remains unchanged. 

For compressed files only, the logical record size has no 
meaning and the requested number of bytes is compressed 
and output. For all other files, a byte count less than, 
equal to, or greater than the logical record size can be re- 
quested and the requested number of bytes, up to the maxi- 
mum of the logical record size, is always output. If the 
byte count is greater than the logical record size, an "in- 
correct length" status is returned. In any case, the file is 
positioned to the next logical record regardless of the byte 
count transferred. 

An "end-of-tape" status is returned when the file is po- 
sitioned at the logical EOT (whether error checking is 
specified or not or if the current operation will cross the 
logical EOT). Data cannot be output past a logical EOT. 

If a Write is attempted on a file that is either logically 
write-protected or on a RAD track that is physically write- 
protected, a "write-protected" status is returned and no 
data is output. 

Since the RAD has no read-after-write capability as do 
magnetic tapes, a separate Check-Write operation is essen- 
tia! to ensure absolute validity of the data cutout; How- 
ever, since a separate Check-Write operation requires as 
much time as the original write operation, and the RAD has 
a high degree of reliability, the capability should only be 



40 



Service Routines 



used when the data is sensitive or cannot be regenerated. 
Backspacing operations must be performed before the Check- 
Write operation, since no repositioning is performed at this 
time. For compressed or blocked files, no Check -Write is 
allowed and a status of "operation not meaningful" will be 
returned. 

Write EBCDIC or Binary on Unblocked Random-Access RAD 
Files. Although a granule size may be specified when a 
random file is defined, the size does not retrict the maxi- 
mum number of bytes that may be written. However, each 
Write operation begins at the start of a granule, and 
uncompleted granules are filled out with zeros. The exact 
number of bytes requested is output; never with "incorrect 
length" status return. If the Write begins or extends beyond 
the file's ending boundary, no data is transmitted and an 
"end-of-tape" status is returned, whether or not error 
recovery is specified. 



If a Write is attempted on a file that is either logically 
write-protected or on a RAD track that is physically write- 
protected, a write-protected status is returned and no data 
is output. 



Write EBCDIC or Binary on Blocked Random-Access RAD 
Files. Any access is restricted to the record size regardless 
of whether the access is random or sequential. Incorrect 
length and end-of-tape may occur. Write protection con- 
siderations are the same as for unblocked random files. 



ADRLST is the pointer to the argument list, which is a 
set of two consecutive words either in the user's pro- 
gram or in a temporary stack. This argument list appears 
as follows. 



word 



F 





w 





-0- 


ORDER 



12 3 4 



7 8 



15 



F - 1 if this is a device-file number. 



if this is an operational label or device unit 
number. 



W = 1 if wait for operation is to be initiated. 

= if no wait for operation is to be initiated 
when device/channel is busy. The W flag 
has a different function for MrCTRL than for 
M:READ/M:WRITE. If the operation is ini- 
tiated, control will not be restored to the 
calling task until the operation is complete. 

ORDER is one of the following pseudo order bytes: 



Note; For all RAD files, no transfer will be initiated 
that will cross a track boundary. Instead, it will 
be broken into two transfers: one to write to the 
end of the track, and a second to complete the 
transfer. Therefore, in a "no-wait" operation, a 
check must be requested to complete the transfer. 
If an AIO Receiver is specified, it will be entered 
each time channel end occurs, but it also must be 
specified in each check operation call which may 
be different from the AIO Receiver given in the 
Write call. 



Order Operation 

X'EB' Space Record Backward 

X'EF 1 Space Record Forward 

X'FB' Space File Backward 

X'FF' Space File Forward 

X'2B' Rewind Off Line 



MlCTRL (General Control Routine) 



X'3B' 



Rewind On Line 



MrCTRL provides device-independent positioning capabili- 
ties for magnetic tapes (both 7-track and 9-track) and for 
sequential RAD files. All MrCTRL control functions are 
exempt from channel time limits. The calling sequence is 



LDX 



ADRLST 



word 1 



Operational label or file number 



15 



RCPYI P,L 
B M:CTRL 



Return is to the location in the L register. The B register is 
always saved. Status is returned in the E, A, and X regis- 
ters, as in MrREAD. 
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Note; For unblocked random-access RAD files, where 
these operations are not meaningful, an "operation 
not meaningful" status will be returned. 



M:CTRL FUNCTIONS 

If the device is a magnetic tape or a sequential RAD file, 
it is positioned as indicated. The record spacing com- 
mands are utilized for physical records and are not mean- 
ingful for FORTRAN logical records. 



S~ acs Record Backw! 



srd. The Space Record Backward orde 



positions a magnetic tape to the start of the previous phys- 
ical record. If the tape is already at load point, the order 
is ignored and a BOT status is returned. If the previous 
record was an end-of-file, EOF status is returned. 



file is positioned immediately beyond or at the logical 
EOF, it is repositioned to the point immediately before 
the logical end-of-file, and EOF status is returned. If the 
file is positioned before the logical EOF, it is repositioned 
to the beginning-of-tape and BOT status is returned. If the 
file is already positioned at the logical beginning-of-tape, 
the order is ignored and BOT status is returned. If the file 
is blocked and there is output data in the blocking buffer, 
it is written on the RAD before the file is repositioned. 

Space File Forward. The Space File Forward order positions 
a magnetic tape to the start of the next file. A status of 
EOF is returned. 

For sequential RAD files, the file is positioned immediately 
at the logical EOF and "EOF" status is returned. If the 
file is already positioned beyond the logical EOF or no 
logical EOF has been written, the order is ignored and an 
"illegal RAD sequence" status is returned. If the file is 
blocked and data has been written in the blocking buffer, 
it will be written out before the file is repositioned. 



For compressed RAD files, this order is illegal and a 
status of "operation not meaningful for this device" will 
be returned. 



Rewind On-Line. The Rewind On-Line order rewinds mag- 
netic tape to the load point. If the tape is already at the 
load point, no error status is returned. 



For sequential RAD files, the file is positioned to the start 
of the previous logical record. If the file is positioned at 
the logical BOT, the order is ignored and a BOT status is 
returned. If the file is positioned immediately beyond 
the logical EOF, EOF status is returned and the file is 
repositioned to the point immediately before the logical 
EOF. If the file is blocked and there is output data in 
the blocking buffer, it is written on the RAD before the 
file is repositioned. 



Space Record Forward. The Space Record Forward order 
positions a magnetic tape ot the start of the next physical 
record. If the record skipped was an end-of-file, EOF 
status is returned. 



For compressed RAD files, this order is illegal and a 
status of "operation not meaningful for this device" will be 
returned. 



For sequential RAD files, the file is positioned to the start 
of the next logical record. If the record skipped was the 
logical EOF, an "end-of-file" status is returned. If the 
file is positioned at the logical EOT, the record is not 
skipped and an "end-of-tape" status is returned. 



For sequential RAD files, the file is positioned to the logi- 
cal BOT. If the file is already at the load point, no error 
status is returned. If the file is blocked and there is output 
data in the blocking buffer, it is written on the RAD before 
the order is executed. 



Rewind Off-Li ne. For magnetic tape, the tape is rewound 
and unloaded. The Rewind Off-Line operation is useful 
for a "save" tape or for a tape at the end-of-reel when a 
new tape must be mounted. The user must control and check 
this condition. 



For sequential RAD files, the file is closed by a call to 
MrCLOSE. If the file is blocked and there is output data 
in the blocking buffer, the data is written on the RAD be- 
fore the order is executed. In addition, the file directory 
is updated on the RAD to reflect the current position of the 
logical file mark. 



M-.DATIME 



(Calendar Date and Time of Day) 



Space File Backward. The Space File Backward order posi- 
tions a magnetic tape to either the start of the previous file 
mark (and EOF status is returned) or load point (if there is 
no file mark). If the tape is already at the load point, the 
order is ignored and BOT status is returned. 

For sequential RAD files, the file is positioned to either 
the start of the logical EOF or to the logical BOT. If the 



MrDATIME provides the calendar date or time of day, or 
both, to either foreground or background programs in 
EBCDIC format. The calling sequence is 



LDX 



ADRLST 



RCPYI P,L 

B MrDATIME 
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ADRLST is the pointer to the argument list, which is a set 
of two consecutive words either in the user's program or in 
a temporary stack. This argument list appears as follows: 

word 



D 


T 


S 





12 3 
where 



15 



D 



= 1 if return calendar date is specified. 

= if calendar date is not required. 

= 1 if return time of day is specified. 

= if time of day is not required. 

= 1 if date and time are supplied by the user (in 
Address and Address + 1). 

= if current date or time of day, or both, are 
to be used. 



word 1 



Address 



15 

where Address is the location where the date and time of 
day are stored. 

Return is to the location in the L register. The B register is 
always saved. 

M:DATIME FUNCTIONS 

If CLOCK lis dedicated at SYSGEN, KrCLOCKin the com- 
munication region is a pointer to the accounting table that 
contains the date and time. The date and time are set at sys- 
tem initialization and can be reset by the operator through un- 
solicited key-ins. The date is automatically advanced and 
provisions are included foryear changes including leap-year 
adjustment. Thus, under continuous operation, only adjust- 
ments to accommodate daylight savings time changes are re- 
quired. The date or time of day, or both, are stored in the 
following format in the area of core specified by word 1 of 
the argument list: 



Date: 



Time: 



M 


M 


^^" 


D 


D 




Y 


Y 


A 


A 


H 


R 


M 


N 



2 blanks are sup- 
plied when both 
date and time are 
requested 



If the date and the time are supplied by the user (S = 1), 
the times supplied in Address and Address + 1 will be over- 
laid by the calendar date or time, or both. This option is 
used by the Job Control Processor ! PURGE command. 

If CLOCK 1 is not a dedicated at SYSGEN date and/or time 
will be solicited from the operator. 



MiTERM 



(Normal Exit from Background Programs) 



M:TERM provides an entrance back to the Monitor on a 
normal termination of a background program. The calling 
sequence is 



RCPTI 



P,L 
M:TERM 



M:TERM FUNCTIONS 

If called by a foreground program, control will be trans- 
ferred to M-.EXIT to perform the exit sequence for that task. 
On calls from the background the L register must be set to 
a background address or the background call will be aborted 
with a protection violation. 

All I/O is allowed to run down. All files utilizing block- 
ing buffers will have their blocking buffers closed out. If 
an unconditional postmortem dump was specified, it will be 
performed at this time. The Control Command Interpreter 
will then be read into the background and will read the 
next control command. 



M:AB0RT 



(Abort Routine) 



Note: Time of day is given in military time (0000-2359). 



When a background program fails for any reason, a call to 
MrABORT provides a method of clearing the background 
program out of core memory and for terminating all active 
I/O for the background program. The calling sequence is 

LDA LOC 

LDX CODE 

RCPYI P, L 

B MrABORT 

CODE is a word of EBCDIC information and LOC is a word 
of hexadecimal information that is printed on the DO and 
OC devices to show why the job was aborted. 

Return is never to the location in the L register. If the call 
is from a real-time foreground program, the task is disabled 
and MrEXIT is called to perform the exit functions. If the 
calling task occupies the nonresident foreground area, an 
unload operation will be performed. On calls from the back- 
ground, the L register must be set to the background or the 
background call will be aborted with a protection violation. 
All I/O in progress is allowed to complete and a postmortem 
dump will be performed at this time if previously requested. 
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M:SAVE 



(Interrupt Save Routine) 



M:SAVE routine performs the full context switching when 
a foreground interrupt occurs. It is available only for fore- 
ground programs that are connected directly to an interrupt. 
The calling sequence is 



RCPYI 



P,L 



MrSAVE 



the previous task, and performs the actual exit sequence. 
The calling sequence is 

RCPYI P,L 
B M:EXIT 

Return is to the interrupted task at the address saved in the 
PSD. All registers are restored to the same value they had 
at the time of the interruption. 



ADRL 



TCB 



where TCB is the address of the Task Control Block for the 
task. 

Return is to the value in the L register + 1. The contents of 
all registers except A and L are transferred to the TCB. 



M : SAVE FUNCTIONS 

The contents of A and L must be saved in the proper place 
in the TCB before the task calls M:SAVE. M:SAVE then 
saves the original value of X, T, B, and E in the TCB. The 
interrupting task has its own floating accumulator set into 
locations 0001-0005 and the previous task's floating ac- 
cumulator pointers are saved. The M:SAVE routine stores 
the temporary stack and TCB pointers in locations 0006 and 
0007 for this current task and saves the old values in the 
interrupting task's TCB. 

If the flag in the TCB is set for "no temporary storage" 
M:SAVE saves only the hardware registers and the TCB 
pointers, and not the full context. 

If Clock 1 has been reserved for RBM accounting, M:SAVE 
will record the start time of the first interrupting foreground 
task and will trigger the RBM Control Task to calculate fore= 
ground run time. 

An additional entry point, M:FSAVE, is available for users 
of the Sigma 3 optional instruction, Store Multiple. This 
entry point, with an address literal in cell X'C7', assumes 
that all registers have been saved, but performs the remainder 
of the functions of M.-SAVE as listed above. The calling 
sequence is 



RCPYI 



ADRL 



P,L 



*X'C7' 



TCB 



where TCB is the address of the Task Control Block for the 
task. 



M:EXIT FUNCTIONS 

The operations performed by MrEXIT are essentially the re- 
verse of those in MrSAVE. It is necessary to inhibit inter- 
rupts for about II microseconds for the actual exit sequence, 
but it is not necessary to call MrEXIT to perform the exit 
sequence if it can be performed by the user's program. 

The TCB contains a flag to indicate whether any temporary 
storage is used. If the task does not use any Monitor I/O 
routines or the floating accumulator, no temporary storage 
is needed. In this case, only the hardware registers are 
restored. 



M:HEXIN 



(Hexadecimal to Integer Conversion) 



The MrHEXIN routine converts a hexadecimal number (rep- 
resented in EBCDIC) to a binary integer. The calling 
sequence is 



LDA 



left 



RCPY A, E 

LDA right 

RCPYI P,L 



B 



MrHEXIN 



where left and right contain the EBCDIC codes for the 
hexadecimal number (the left and right part of a possible 
four-byte field). 

Return is to the location in the L register. The result is in 
the A register, the X register is changed, and the B register 
is unchanged. 



MlEXIT (Interrupt Restore Routine) 

MrEXIT restores the contents of all registers prior to exit 
from a foreground task, switches the full context back to 



M:HEXIN FUNCTION 

Blanks and zeros are treated as hexadecimal zeros. No tem- 
porary storage is used and no error checking is performed. 
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MMNHEX (Integer to Hexadecimal Conversion) 

The M:INHEX routine converts a binary integer to a hexa- 
decimal representation in EBCDIC code. The calling se- 
quence is 

LDA integer 

RCPYI P,L 

B M:INHEX 



word 1 



1 if checkpoint is to be performed at the level of 
the callingtask (meaningful only if C = 1). 

if checkpoint is to be performed at the level 
of the RBM Control Task (meaningful only 
if C - 1). 



Checkpoint Complete Receiver 



15 



where integer is the value to be converted. 

Return is to the location in the L register. On return, the 
E register contains the leftmost two bytes, and the A regis- 
ter contains the rightmost two bytes. The X register is 
changed, but the B register is unchanged. 



MrlNHEX FUNCTION 

Four fields of four-bit hexadecimal codes are converted to 
four fields of eight-bir EBCDIC equivalents. No temporary 
storage is used. 



The Checkpoint Complete Receiver should be used like an 
AIO Receiver. That is, after requesting a checkpoint, the 
foreground program should release control by a call to 
M:EXIT and regain control through the specified receiver 
address when the checkpoint operation is completed. Only 
a foreground program can checkpoint the background; a 
background program cannot checkpoint the background area. 

Return is always to the location contained in the L register. 
The B register is always saved. The A register contains the 
status (1 if operation is impossible; if successful). 



M:CKREST FUNCTIONS 



MlCKREST (Checkpoint/Restart Background) 

MrCKREST checkpoints the background (i.e., writes it out 
onto a predefined area on the RAD), turns the background 
space over to the foreground program, and then restarts the 
background when requested. The calling sequence is 



LDX 

RCPYI 
B 



ADRLST 

P,L 

M:CKREST 



ADRLST is a pointer to an argument list, as follows: 



word 



C 


R 


P 





12 3 



15 



Checkpoint. All active I/O for the background is allowed 
to complete but no error recovery is performed for this I/O 
until the background is restarted. Peripheral devices dedi- 
cated to the background should not be repositioned. 

When all I/O has terminated, the entire background space 
is written out onto a prespecified area of the RAD and the 
background is set "protected". If the background is truly 
"empty 1 when the request is made, the checkpoint is per- 
formed immediately, and no RAD is required for the check- 
pointing procedure. If a Checkpoint Complete Receiver 
was specified, it will be entered with the L register set 
to the return address and will be run at the RBM Control 
Task level. 

A checkpoint operation will be automatically performed 
while loading a nonresident foreground program that extends 
into the background. When the active nonresident program 
unloads (see Monitor service routine M:LOAD), the back- 
ground will be automatically restarted. When the check- 
point operation is completed, the message I !BKG CKPT is 
output to inform the operator. 



where 
C 



= 1 if request is to "checkpoint" the background. 

— if request is to "restart" the background. 

= 1 if a Checkpoint Complete Receiver is to be 
informed when the checkpoint is complete. 
(Valid only if C = 1 and P = 0. ) 

= if no Checkpoint complete Receiver is used. 



Restart. A restart is always performed at the priority level 
of the RBM Control Task. It is assumed that no peripherals 
have been repositioned. The core allocation table is re- 
stored to the previous value before the checkpoint took 
place, and the background is then loaded in from the RAD 
and continues as before. 



This would occur after a !FIN command was encountered 
or when the Monitor was in an idle state after an abort of 
an attended job. 
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If no background program was in progress when the check- 
point was called for, the background is set to an unprotected 
status but no attempt is made to reload a program from the 
RAD when the foreground terminates. 

The message ! ! BKG RESTART is output to inform the opera- 
tor that the background has been released by the foreground. 
See Chapter 6 for more details. 



M:L0AD 



(Absolute Core Image Loader) 



M:LOAD initiates the loading of the root segment of a resi- 
dent or nonresident foreground program by entering the re- 
quested program name into the queue stack. It also initiates 
the loading of the root segment of a resident or nonresident 
foreground program or background processor upon request 
from the Job Control Processor. It releases (unloads) the 
nonresident foreground space for use by the next program 
in the queue. 

The calling sequence is 
LDX ADRLST 

RCPYI P,L 

B M:LOAD 

ADRLST is a pointer to an argument list, as follows: 



word 1 



DFN or CI and C2 



15 



word n 



C7 


C8 



15 



where 



DFN 



is the device-file number. 



' C1-C8 is the program name (must be 8 characters, 
including trailing blanks). 

Return is always to the location in the L register. The con- 
tents of the B register are always saved and the A register 
contains status codes, as follows: 

A Register Meaning 



Operation is successful. 

Request cannot be honored at this time 
(this could occur if Q = and a non- 
resident foreground area was already 
committed; or if Q = 1 and the queue 
stack was full). 



word 



p 


Q 


U 






12 3 



where 
P 



Q 



15 



1 indicates a request to read from the specified 
device-file number (word 1). The device- 
file number must currently be assigned to a 
RAD file. (This option is restricted for use 
by the Job Control Processor. ) 

indicates a request to read the specified non- 

resident foreground program from the user's 
processor RAD area. The program name is 
given in C1-C8. 

1 indicates the request is to be queued if it 

cannot be satisfied now. 

indicates the request is to be ignored if it 
cannot be satisfied now. 



1 indicates an unload operation, in which case 
n I <^i _^* _~_„:„«£,,l 

T unu Vj( UIC liui lliciiuniyiUK 

indicates a load operation. 



M:LOAD FUNCTION 

After saving the nonresident program name or device-file 
number request, M:LOAD triggers the RBM Control Subtask 
S:LOAD and then exits to the location in the L register. 

The actual loading of the program is accomplished at the pri- 
ority level of the RBM Control Task. S:LOAD will ensure 
that sufficient blocking buffers are available for those oper- 
ational labels contained in the header record of the proces- 
sor. If the request was for a nonresident foreground program 
that extends into area reserved for the background, S:LOAD 
automatically causes the background to be checkpointed. 

It is essential that each nonresident program executed in the 
nonresident foreground area terminate itself by a call to 
M:LOAD to unload, disable itself, and then exit via the 
normal interrupt exit routine (M:EXIT). This will release 
the nonresident foreground area for subsequent loads. 

For an unload request, M:LOAD triggers the RBM Control 
Task routine S:LOAD for the next load if any other entry is 
in the queue stack. If no additional requests are present 
and SrLOAD has checkpointed the background, S:LOAD 
triggers RBM Control Task S:REST for a restart. 

Note that M:LOAD inhibits interrupts for a short period 
while manipulating the queue stack (less than 100 psec if no 
more than eight entries are waiting in the queue). 
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M:OPEN 



(RAD File Open) 



A Register Meaning 



M:OPEN reserves a blocking buffer from a buffer pool or a 
specified location, for a sequential blocked RAD file to 
which an operational label or device unit number had pre- 
viously been assigned. 

The calling sequence is 
LDX ADRLST 

RCPYI P,L 

B M:OPEN 

ADRLST is a pointer to the three-word argument list shown 
below. 

word 



1 2 

where 
F 



15 



1 if a device-file number (DFN) is specified 
(internal Monitor calls only). 

if an operational label or device unit num- 

ber is specified. 

1 if a blocking buffer location is included in 

this call. 

if no blocking buffer location is included, in 
which case MrOPEN attempts to find space 
in the task's buffer pool. 



word 1 



Operational label, device unit number, or DFN 



15 



word 2 



Address of blocking buffer (optional) 



15 



Return is to the location in the L register. The B register 
is restored. The following status information is contained 
in the A register on return. 

A Register Meaning 

Operation successful. 

1 Blocking buffer already defined. 



2 No space available in buffer pool. 

3 Illegal operational label or operational 
label unassigned. 

4 Not RAD file, or not a blocked RAD file. 

5 Blocking buffer outside of background 
for a file assigned to the background. 

6 Illegal DFN. 

MrOPEN FUNCTION 

The address of the blocking buffer (either the one specified 
or one located from the task's buffer pool established by an 
ABS or $BLOCK command) is stored in the File Control 
Table. If no open request has been performed for a sequen- 
tial blocked file by the user's program, M:READ, M:WRITE, 
or M:CTRL will call M:OPEN to allocate a buffer from the 
blocking buffer pool on the first data transfer operation. 



M:CL0SE 



(RAD File Release) 



M:CLOSE releases a RAD file (including the blocking buf- 
fer if any) or releases the blocking buffer for a blocked file, 
but retains the file assignment. In either case, partially 
filled blocking buffers are written onto the RAD. The call- 
ing sequence is 



LDX 



ADRLST 



RCPYI P,L 

B MrCLOSE 

ADRLST is a pointer to the argument list, as follows: 
word 



F 


R 


B 






1 
where 



2 3 



15 



- 1 if a device-file number is specified. 

= if an operational label or device unit number 
is specified. 

= 1 if the device-file number is to be released. 

= if the device-file number and operational 
label remain assigned but the blocking buf- 
fer is to be released (the file is not to be 
repositioned). 

- 1 is a buffer is specified. 
= if no buffer is specified. 
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word 1 



Operational label, device unit number, or DFN 



15 



word 2 



Buffer location (optional) 



15 



Return is always to the location in the L register. The 
B register is always restored to its former value. The A reg- 
ister contains the following completion status. 



A Register Meaning 

Successful. 

1 Illegal DFN. 

2 The operational label is not assigned 
to a RAD file. 

3 Illegal operational label. 

4 I/O error writing blocking buffer or 
EOF onto RAD. 

5 No buffer available to complete the 
close operation. 

M : CLOSE FUNCTIONS 

If the file is blocked and data has been written on it, the 
contents of the blocking buffer are written onto the RAD. 

If the blocking buffer was allocated from the task's buffer 
pool, the buffer is released. The EOF is written on the RAD. 

If R = 1, F = 0, and the operational label has a permanent 
assignment, the label is set to that value. If the label has 
no permanent assignment, the label is deleted from the table 
of operational labels. 

If an EOF has been written on the file it must also be 
written onto the RAD. To accomplish this, MrCLOSE re- 
quires a buffer into which the file directory is read. If no 
buffer is specified, MrCLOSE attempts to allocate a buffer 
from the task's buffer pool (or will use the one already 
opened for this file if it is blocked). If no buffer is avail- 
able and an EOF is to be written, the file is not closed and 
an error completion code is returned. 



M:DKEYS 



(Read Data Keys Routine) 



M:DKEYS provides a means for background programs to read 
the data keys on the processor Control Panel. The calling 
sequence is 



RCPYI 
B 



M:DKEYS 



Return is to the location in the L register. The contents of 
the B register are always saved. The contents of the data 
keys are in the A register on return. 



MlWAIT 



(Simulated Wait Instruction) 



M:WAIT provides a means for background programs to exe- 
cute a Wait instruction from nonprotected memory. The 
calling sequence is 



RCPYI 
B 



P,L 
M:WAIT 



The return is to the location in the L register. The B regis- 
ter is always saved. The return does not take place until 
the operator performs an unsolicited S key-in. 

The Monitor types out the message 

!! BEGIN WAIT 
and goes into a wait loop. 

Only a background program may use M:WAIT; a call from 
a foreground program results in a no-operation. 



M:SEGL0 



(Load Overlay Segments) 



M:SEGLD loads and/or executes an overlay segment, for 
either the foreground or background, from a file previously 
prepared and saved on the RAD by the Overlay Loader or 
the Absolute Loader. 

The calling sequence is 
LDX ADRLST 

RCPYI P,L 

B M:SEGLD 

ADRLST is a pointer to the argument list. 

word 



W 


L 


R 





Segment ID 



12 3 



7 8 



15 



where 

W 



1 if an unconditional wait for completion is 
specified. 

if loading is to be initiated only; control 
will be returned to the calling program. 
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1 control is to be transferred to the transfer 
address of the segment just loaded (valid 
only if W= 1). 

control is to be returned to the calling 

program. 

1 there is a "loading complete" receiver 

(meaningful only if W - 0). 

no "loading complete" receiver. 



word 1 



Operational label 



15 



The operational label is used to control the loading of the 
segment. The file must previously have been defined as a 
RAD file and set to the proper overlay program on the RAD. 
Background programs should use operational label PI. 

word 2 



ADRL of OV:LOAD 



15 



The symbol OV.-LOAD must be declared as an external 
reference and is set by the Overlay Loader to the value of 
the Overlay Loader Control Table address in core. 

If the program is assembled in absolute form, the Absolute 
Loader will create the OV:LOAD table at the end of the 
root. Therefore the last item in the root would normally be 
an OV: LOAD EQU $. 



B register is always saved. On the return, the A register 
contains status showing the completion code, as follows: 

A Register Meaning 

Operation complete and successful. 

-1 Irrecoverable I/O error. 

2 Invalid call. 



M:SEGLD FUNCTIONS 

A core table of 5n+ 1 words is maintained at the end of the 
user's root segment that defines the actual RAD- addresses 
for the overlay segments. (OV:LOAD points to this table; 
n is the number of segments in the program.) The segments 
may be loaded in any order because of the random-access 
capability of the RAD. Using the Loading Complete Re- 
ceiver and associated procedures can achieve greater effi- 
ciency in foreground loading. 



M:DEFINE 



(RAD File Definition) 



M:DEFINE allocates a portion of the background temporary 
file area on the RAD for temporary use by the designated 
operational label or device unit number. This call is 
applicable to foreground operations only if the file is 
previously assigned to a permanent RAD file. The calling 
sequence is 

LDA FAVAA (FORTRAN programs only) 

LDX ADRLST 

RCPYI P,L 

B MrDEFINE 



word 3 



Loading Complete Receiver 



15 



The Loading Complete Receiver is permissible only for fore- 
ground programs and should be used in the same way as an 
AIO Receiver. That is, after loading is initiated the fore- 
ground program should release control by a call to M:EXIT 
and regain control through the specified receiver address 
when the overlay operation is completed. 

On all calls specifying an "initiate only", a check operation 
must be performed on the operational label designated to de- 
termine the status of the load and to release the associated 
device-file number for subsequent use. 

On entry, return is to the location in the L register if the 
L parameter in word of the calling sequence is"0"; other- 
wise, control is returned to the newly loaded segment. The 



FAVAA signifies the FORTRAN Associated Variable 
Absolute Address. It is meaningful only if K = 1. 

ADRLST is a pointer to a four-word argument list, 
word 



F 


WP 





K 


G 



2 3 4 5 



8 9 10 



15 



File Format Byte 



where 



specifies the file format as follows: 

000 Blocked 

001 Compressed 
010 Unblocked 

100 Random, blocked 
110 Random, unblocked 
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WP 



= 11 if RBM write protection is specified. 

= 10 if foreground write protection is specified. 

= 01 if background write protection is specified. 

= 00 if write protection is not desired. 

= 1 if the A register contains the FAVAA. 

= if FAVAA is not specified. 

= 1 if a granule size for random files is spec- 
ified; otherwise, the granule size is deter- 
mined by the sector size of the reference 
device (meaningful only if F = 110). 



word 1 



Operational label or device unit number 





where 

operational labels are EBCDIC 
device unit numbers are binary 

word 2 



15 



Number of logical records in file 



15 



word 3 



Logical record size, or granule size if G=l (bytes) 



15 



The number of logical records in the file and the logical 
record size are used to calculate the actual temp space 
required. For compressed EBCDIC files, n card images can 
normally be accommodated by n/3 80-byte records. Thus, 
12,000 card images would require 4000 80-byte records 
(about 83 tracks on a 360-byte per sector RAD). For 
blocked, uncompressed files, the total area in sectors equals 
the number of records requested, divided by the number of 
logical records per sector. Thus, 120-byte binary card 
images can be placed three per sector on a 360-byte-per- 
sector RAD. A 300-card deck would therefore require 
100 RAD sectors (seven tracks). If G = 1 and F = 1 10, the 
file size is computed using the granule size in word 3. 

If this is a random file and G = 0, then the logical record 
size is actually the FORTRAN random I/O logical record 
size and the granule size is equal to either the physical 



sector size for temporary files, or to the granule size defined 
at file ADD time for permanent files. 

For unblocked records, the total area in sectors equals the 
number of records requested multiplied by the number of 
sectors required for each record. 

Return is to the location in the L register. The B register is 
restored. The A register contains status information on the 
return, as follows: 

A Register Meaning 



Operation successful. 

Calling sequence error. Logical record 
size is not an even number or records 
requested. 

Operational label invalid (foreground) 
or no spare entry in operational label 
table. 

No more device-file numbers for the 
RAD. 

RAD overflow (files too large). 

K = 1 and attempted to define pre- 
viously defined file with a different 
FAVAA. 



M:DEFINE FUNCTIONS 

For the specified temporary file, the appropriate size is 
allocated from the pool of temporary file space if such space 
is available. An unused device-file number is then initial- 
ized with the boundary points of this RAD file* All subse- 
quent references to this file (until closed by a call to 
M:TERM, M:ABORT, or MrCLOSE) will refer to the allo- 
cated area. The file is set to the "rewound" condition, if 
it is a sequential file. 

If the operational label is already assigned, no error status 
is returned if it is assigned to a background RAD file. If 
K = 1, the address of the FORTRAN Associated Variable 
from the call must be the same as the one for the file. 

Note: M:DEFINE uses locations 1-3 (of the calling pro- 
gram's floating accumulator) for temporary storage. 



M:ASSIGN 



(Assign RAD Files) 



M:ASSIGN performs equivalence between an operational 
label or FORTRAN device unit number, and 

1. A RAD area. 

2. A file name within a RAD area. 

3. A device-file number. 

4. Another operational label or device unit number. 
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The calling sequence is 
LDX ADRLST 

RCPYI P,L 

B M:ASSIGN 

ADRLST is a pointer to an argument list of two to eight 
words, as follows: 

word 



word 1 



TY 


F 


A 





D 



12 3 

where 
TY 



12 13 



15 



00 if the label is to be assigned to another 
label. 

01 if the label is to be assigned to a device- 
file number. 

10 if the label is to be assigned to a RAD 



= 1 1 if the label is to be assigned to a file 
within a RAD area. 

= if the label is a background operational label. 

= 1 if the label is a foreground operational label. 

= 1 if the two-letter area mnemonic is contained 
in word 3; otherwise, D will specify the 
area. If A is set, D will be ignored. A must 
always be set for areas other than SP, SD, 
SL, UP, UD, UL, BT, and CP. 



D = directory to be used: 

000 Checkpoint area (area only) 

001 System Processor area 

010 System Library area 

011 System Data area 

100 Background Temp area (area only) 

101 User Processor area 

1 10 User Library area 

1 1 1 User Data area (UD only) 

No named files may exist in either the Checkpoint or Back- 
ground Temp areas. D is ignored for TY = 00 or 01. 



oplb(l) 



15 



where oplb (1) is the operational label or device unit to be 
assigned. 

word 2 



opbl (2), DFN, or buffer address 



15 



where 



oplb (2) if present, indicates that oplb (1) will be 

assigned to the device-file number that oplb (2) is 
currently assigned to. 

DFN if present, is the device-file number that 

oplb (1) will be assigned to. 

buffer address is the first word address of a buffer 

(equal to one blocking buffer in length) that will 
be used by M:ASSIGN as temporary storage for the 
appropriate RAD area dictionary. This is mean- 
ingful only for TY = 11. 



word 3 



CI or Al 


C2 or A2 



7 8 



15 



If A (of first word of argument list) = 1, word 3 contains 
the two-letter area mnemonic, Al and A2; otherwise, 
word 3 contains the first two characters of the file name, 
as continued below: 

word 3 + A 



CI 


C2 



15 



word 6 + A 



C7 


C8 



7 8 



15 



C1-C8, if present, is the name of the file to which oplb (1) 
is to be assigned. That is, this file on the RAD is to be 
linked to an unassigned RAD device-file number to which 
oplb (1) is, in turn, assigned. This is meaningful only for 
TY = 11. 
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Return is to the location in the L register. The B register is 
restored. The A register contains status information on the 
return as follows: 

A register Meaning 

Successful operation. 

1 Mixed oplbs or device-file numbers 
(foreground to bakcground or vice 
versa). 

2 Invalid oplb (2) or DFN. 

3 No spare entries in oplb or DFN tables. 

4 File name not found in designated 
directory. 

5 RAD area not allocated. 

6 Illegitimate RAD file format. 

When the A register = 0, the X register will contain the 
standard record size of this device. 



M:ASSIGN FUNCTIONS 

MrASSIGN may be called to make any of four types of 
assignments, according to the setting of TY, as follows: 

TY = 00 oplb (1) is assigned to the DFN to which 

oplb (2) is currently assigned. Oplb (2) 
must be the same mode (foreground or back- 
ground) as oplb (1) (error return A = 1). A 
background program cannot assign fore- 
ground oplbs (error return A = 1). 

= 01 oplb (1) is assigned to the specified DFN. 
DFN must be legal, must not be a RAD 
DFN, and may not be foreground if 
oplb (1) is background. 

= 10 oplbl (1) is assigned to a currently unused 
RAD DFN which, in turn, is linked via 
the RBM Master Dictionary to a current 
RAD area. The area may then be used 
exactly like a RAD file with the following 
characteristics: 



Format: 

Logical record size: 

Write protection: 



BOT 
EOF 
EOT 



random 

sector size 
in bytes 

area write- 
protect code 

BOT of area 

none 

EOT of area 



return A = 5). The buffer address must be 
in the background if the calling program 
is a background program. 

If there are no errors, the assign will take place regardless 
of the prior status of oplb (1). For TY - 10 and II, RAD 
files are rewound (file pointer is set to BOT). For TY = 00 
and 01, the file position is unchanged. 



M:RES 



(Temporary Storage Allocation Without Transfer) 



M:RES allocates storage in a temporary stack, saves the 
previous value of B, and sets B to the first word address of 
temporary area being allocated. The calling sequence for 
dynamic allocation of storage is 



RCPYI 


P, 1 


B 


*$ + 3 


DATA 


n 


DATA 





ADRL 


M:RES 



where n is the number of cells to be reserved. 

T must point to the background if it is a background 
program. 

A TS abort will occur if more temporary storage is requested 
than is available. 

The calling sequence for nondynamic allocation of storage is 



RCPYI 


P,T 


B 


*$ +3 


DATA 


n 


ADRL 


TEMP 


ADRL 


M:RES 



where TEMP is the address of n reserved locations at the end 
of the calling program. This area must not contain any code 
or literals for Public Library routines. 

Upon return, the B register contains the pointer to the new 
temporary storage stack. Locations and 1 relative to the 
base register are used by the storage allocation routines and 
may not be used by other routines. Location 2 relative to 
the base (the return address for M:POP) is set to M:ABORT. 

The calling program can set up its own exit through M:POP 
via the following. 



= 11 oplb (1) is assigned to a currently unused 
RAD DFN, which in turn is linked via the 
RAD dictionaries to an individual file 
within an area (e.g., XSYMBOL). The 
RAD area must currently be accessible (error 



LDA 



=RETURN 



The L and X registers are unaffected. 
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M:POP 



(Temporary Storage Release Routine) 



A call to M:POP is made to release the current TEMP stor- 
age stack (pointed to by the current value in the B register), 
restore the previous value to B, and return to the location 
specified in TEMP + 2. 

If the temporary storage was allocated by M:RES, the call 
must set up a return in TEMP + 2. The calling sequent is 



LDA 


-RETURN 


STA 


2,,1 


RCPYI 


P,L 


B 


M:POP 



when RETURN is the location to which return will be made 
after the stack is released. 

L must always be set, even for foreground tasks. 

Return is to the address specified in location 2, relative to 
the beginning of the stack being released. The location in 
the L register and the return address must be in the back- 
ground area if return is to a background program. On re- 
turn, B contains its previous value before the RES-POP 
sequence. Assume return is made to location R; L is set to 
the value R + 1. 



MlOPFILE (Convert Operational Label to Device-File 

Number) 

MrOPFILE determines the file to which a foreground or 
background operational label is assigned. The calling 
sequence is 



LDA 


TYPE 


LDX 


ADRLST 


RCPYI 


P,L 


B 


MrOPFILE 



/here 



TYPE is the mode of the operational label; nega- 

tive for foreground, positive for background. 



If E is positive, the following information is provided. 
Register Contents 



Device-file number 
IOCT entry address 
Operational label table entry 



Note: This routine is used primarily by the RBM and certain 
processors. Itwill seldom be needed by user programs. 

M:RSVP (Reserve or Release Peripherals) 

M:RSVP reserves a peripheral device for foreground use 
only, until the foreground voluntarily releases the device. 



LDX 


ADRLST 


RCPYI 


P,L 


B 


MrRSVP 



ADRLST is the pointer to the argument list, which consists 
of three consecutive words either in the user's program or 
in a temporary stack. This argument list appears as follows: 

word 



F 


U 


R 


T 




Device number 



12 3 4 
where 



15 



= 1 if request is "reserve for foreground". 

= if request is "release to background". 

= 1 if request is for an unconditional reserve, 
where operator intervention is not required. 

= if request is for a conditional reserve, where 
operator intervention is required. 

= 1 if a receiver is to be entered when the con- 
ditional reserve is completed (only meaning- 
ful if U = 0). 

= if no such receiver is to be used. 

= if a device type is not specified. 

= 1 if a device type is specified (used to distin- 
guish KP40 from PT40). 



ADRLST is a pointer to the operational label. 

Return is to the location in the L register. The B register 
is saved and restored. The status is contained in the E reg- 
ister as follows: 

E = negative if label is not found 

E = positive if label is found 



word 1 



Reserve Complete Receiver (optional) 



15 



See the chapter on SYSGEN for a discussion of the I/O 
Control Table and the Operational Label Table. 



Service Routines 



53 



A Reserve Complete Receiver should be used like an AIO 
Receiver; namely, after the request has been acknowledged, 
the foreground program should release control by a call to 
MrEXIT and should regain control when the reserve has 
been effected through the specified receiver address. This 
receiver is entered at the priority level of the RBM Control 
Task and should return to the location contained in the 
L register. If R = 0, word 1 contains the device type (see 
word 2). 

word 2 



Device type (e.g., KP) (optional) 



15 



Keturn is always to the iocation contained in the L register. 
The A register contains status as follows: 

A = if the request is acknowledged. If F = 1 
and U = 1 (i.e., unconditional reserve), the de- 
vice is reserved for foreground use. If F = (i. e. , 
release), the device has been released for back- 
ground use. 

A = 1 if the request is acknowledged but operator 

intervention is required. If a Reserve Complete 
Receiver is specified, it is entered when the oper- 
ator effects the reserve. This is the normal re- 
sponse to a conditional request to reserve a 
peripheral device (F = 1, U = 0). 

A = 2 if the device is not associated with a back- 
ground file. 

A = -1 if the request cannot be honored because a 

prior request to reserve this device has been made, 
if the request is to release an unreserved device, 
or if the reserve peripheral table (RSVTBL) is fuli. 
(See "Limitations" below.) 

M:RSVP FUNCTIONS 



Reserve. If the request is for an unconditional reserve, a 
message is output to inform the operator of the foreground 
reserve action (e.g., !!FG RESERVE, LP02). 

If the request is for a conditional reserve, a message is out- 
put to inform the operator of the request (e.g., !!FG 
REQUEST, CR03). The operator should then prepare that 
device for the pending foreground operation, and then re- 
serve the device by an unsolicited key-in of FR (foreground 
reserve; for example, FR CR03). This will reserve the de- 
vice for foreground use. A message is now output to acknow- 
ledge the reserve action (e. g. , ! ! FG RESERVE, CR03). If 
the Reserve Complete Receiver is specified, it will be 
entered at this point. 

Release. The peripheral device can be released for back- 
ground use by a call to M:RSVP to release the device. 
The peripheral device specified will now be available for 



background use. A message will be output to infrom the 
operator of the release action (e.g. , ! !BK RELEASE, CR03). 
The peripheral device can also be released by an unsolicited 
key-in of BR (background release). Unsolicited key-ins to 
reserve and release peripheral devices are described in 
Chapter 3. 



Limitations. The reserve peripheral table will accommo- 
date five requests at a time, which is felt to be a realistic 
limitation. 



M:D0W 



(Diagnostic Output Writer) 



Currently, multitask use of the saem file may result in a 
conflict situtation whereby a task is unable to output a 
message because a lower priority task has control of the file. 
M:DOW allows the use of an active file for the purpose of 
outputting alarms. The calling sequence is 



LDX 

RCPYI 

B 



ADRLST 

P,L 

M:DOW 



ADRLST is a pointer to the four-word argument list as 
shown below: 

word 



1 



15 



1 if a device file number is specified. 

if an operational label or device unit number 
is specified. 



word 1 



Operational label or file number 



15 



word 2 



Address of buffer containing data 



15 



word 3 



Number of bytes to transmit 



15 
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Return is to the location in the L register. The B reg- 
ister is always saved- The status is returned in the E, 
A, and X registers. The method of returning and the 
status returned are the same as described under MrREAD/ 
MrWRITE. 



M.-DOW FUNCTIONS 

If the file to be used is currently active, M:DOW will 
wait until end-action-pending and will then clear the 
active file and the end-action-pending flags. The call 
will be translated to an equivalent call to MrWRITE which 
will be output the alarm. The buffer data are assumed 
to be EBCDIC. 



MiCOC (Character-Oriented Communications) 

M:COC performs input, output, and control operations on 
a specific communication line. The calling sequence is 

LDX ADRLST Pointer to the argument list 

RCPYI P,L Set the return address 

B M:COC Branch to the routine 

ADRLST is a pointer to the argument list, as follows: 



word 




Order 


word 1 


E 


Line number 


Prompt character 


word 2 


Buffer address 


word 3 




Byte count 


word 4 


EOM Receiver 



1 78 11 12 15 

where 

Order (bits 12-15) is as follows: 

Order Operation 

Check status of line 

1 Write n bytes, no editing 

2 Read n bytes, no editing 

3 Send break character (long-space) 

4 Check previous read or write 

5 Write message of up to n bytes, edited 

6 Read message of up to n bytes, edited 



Order Operation 

7 Disconnect line (turn off data set) 

8 Connect line 

where n = < n < 255. 

E is 1 if an end-of-message (EOM) receiver is 

specified; is if no EOM receiver is specified. 

Prompt character is meaningful on duplex lines for 

orders 6 and 8. For order 6, it is the character 
(EBCDIC) to be output before input is requested. 
This can be used to signal the operator that input 
can now begin. For order 8, it specifies the mode 
in which all communication will be handled on this 
line until it is disconnected, and it has the follow- 
ing form: 

Bit Value Meaning 

8 1 Echo all input characters. 
Do not echo. 

9 1 Translate all input from 7-bit 

ANSCII to EBCDIC, and all 
output from EBCDIC to ANSCII. 

Do not translate any codes. 

10 1 Check parity on input and create 

parity on output (even parity). 

Ignore parity 

11-12 00 Device is Model 33/35 teletype. 

01 Device is Model 37 teletype. 

10 Device is keyboard/display. 

11 Device is foreign device, and no 
editing or translation will be per- 
formed (overrides setting of 

bits 9 and 10). 

14-15 Communication Mode (for connect 

order) 

00 Full deplex (echoing accepted) 

1 1 Half duplex (echoing not accepted) 

10 Simplex-receive 

01 Simplex-send. 

EOM Receiver is used like an AIO Receiver. When 

an input or output message is completed, the 
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appropriate communications task will branch to the 
specified EOM receiver address, at the priority 
level of either the input or output external in- 
terrupt, and will show the line number (of the line 
with the completed message) in the X register. 
The user program should save this status, trigger 
an appropriate user interrupt level, and return to 
the location in the L register. All operations are 
no-wait operations; that is, the return is immediate 
upon initiating I/O or performing the connect or 
status checks. Thus, the EOM receiver is 



applicable only for read (2 and 6), write (1 and 5), 
and send break (3) orders. EOM receivers are 
subject to the same restrictions and precautions as 
are AIO receivers. (See Chapter 5 for a more de- 
tailed discussion of AIO receivers. ) 



Return is to the location specified in the L register. On 
return, the B register remains unchanged; and the E, A, 
and X registers are set as specified in Tables 11, 12, 
13, and 14. 



Table 11. Status Returns for M.-COC 



Operation 


Major Status 


Action 


E 


A 


X 


All operations 


Line no. not valid 


Return 
immediately 


-1 


8 


Line no. 


Calling seq. err. 


-1 


4 


Line no. 


Line has disconnected 


-1 


2 


Line no. 


Invalid line status 


-1 


1 


Line no. 


Initiate read 
or write 


Line is busy 


Return 
immediately 





-1 


Line no. 


Successfully initiated 


Initiate and 
return 








Line no. 


Check previous 
input or output 


Line is busy 


Return 
immediately 





-1 


Line no. 


Operation complete 


Return 





Completion 
code 


Byte count 


Connect or 
disconnect 


Successful connection 


Connect and 
return 








Line no. 


Check status 


Connected line 


Test and 
return 


Line 
status 


Line mode 


Line no. 



Table 12. Completion Codes 



Table 14. Line Mode 



A Register Value 


Meaning 



1 
2 


Successful completion 

Parity error on some byte read 

Break condition exists 



Table 13. Line Status 


E Register Bits 


Meaning 


0-11 


Not used 


iz.- io 


Receiver status (O and C bits) 


14-15 


Transmitter status (O and C bits) 



A Register Value 


Meaning 





Line is disconnected 


1 


Output mode 


2 


Output prompt character and 
then switch to input 


3 


Input mode 


4 


Inactive mode 


5 


Message complete 
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The nine possible orders that can appear in the argument 
list, and the operation for each, are described below: 

Check status of line. This operation allows the 
user to check both the logical condition of the line 
(which must be one of the unique codes in Table 14) 
and the physical condition of the line (which is 
reported fust as it is received from the hardware). 
Only the line number is needed in the argument list. 

1 Write n bytes, no editing. If the byte count is 
odd, the first output transmission takes place 
from right of the first word, and the left of the 
first word is ignored. No end-of-message codes 
are added at the end of the message, and no 
trailing blanks or null characters are stripped 
off. Parity generation and translation from EBCDIC 
to ANSCII are under the control of the specified 
options for this line. 

2 Read n bytes, no editing. A read operation is 
initiated, with no editing for cancel or character- 
delete operations, but with a search for any 
ANSCII control character. Input is terminated 
if any control character is found or if the speci- 
fied byte count is exhausted. If any input bytes 
were received before this read request was given, 
these bytes are thrown away. The end-of-message 
character always remains in the user's input buf- 
fer, translated to EBCDIC, if specified. The 
same comments about parity apply for the write 
operations. 

3 Send break character (long-space). If the line is 
in an inactive mode, the long-space is sent 



immediately. If the line is in a write mode or a 
read mode, the operation is terminated and the 
long-space is then sent. In the argument list, only 
the line number is meaningful. 

Check previous read or write. This operation is 
required for all read and write operations, whether 
or not an EOM receiver is specified. The user 
buffer remains busy until the previous operation is 
checked. The line is then set inactive and be- 
comes ready for subsequent use. This is the only 
way to determine break conditions. The return 
status is shown in Tables 11 and 12. Only the line 
number is meaningful in the argument list. 

Write message of up to n bytes, edited. This op- 
erates like the write operation without editing 
except (1) that trailing blanks and trailing null 
characters are removed and (2) that appropriate 
control characters are added as the final charac- 
ters of the message. 

Read message of up to n bytes, edited. This oper- 
ates like the read without editing, except that 
ignore, backspace, and cancel operations are in 
effect for the current line; when any of these 
special characters are encountered, the proper 
effect takes place on the line and the user's buf- 
fer is modified accordingly. (Note that the 
backspace is an editing, or destructive, backspace; 
that is, the previous character is deleted from the 
user's buffer.) The prompt character, if nonzero, 
is output prior to the read operation. (See Table 15 
for a summary of editing operations.) 



Table 15. Summary of Editing Operations 







Codes Used 


Operation 
















33/35 


37 


Character Display 


User-generated end-of-message 


CR or LF or BREAK 


NL or BREAK 


NL or INTERRUPT 


character on input, edited 








System-generated end-of- 


LF or CR (opposite of 


None for NL; 


None for NL; NL for INTERRUPT 


message character on input 


user input); 

CR and LF on BREAK 


NL for BREAK 




Attention code; used to 


BREAK 


BREAK 


INTERRUPT 


terminate input or output 








Ignore this character, except 


RUBOUTor 


DEL or 


DEL or 


after ESC 


ESC, SPACE 


ESC,SPACE 


ESC, SPACE 


System-generated characters 


CR,LF,RUBOUT 


NL,RUBOUT 


NL,5 - NULL 


on output at end-of-message 








Delete previous character 


ESC,RUBOUT 


ESC,DELETE 


ESC,DELETE or EM 




(echo- — ) 


(echo\) 


operation 


Delete current line 


ESC,X 


ESC,X 


ESC,XorCR,CAN 
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7 Disconnect line. The send and/or receive mod- 
ules of the line are turned off and the logical 
status is set to disconnect. 



Connect line. The communication mode option 
for the line, simplex or duplex, is matched against 
the physical structure of the line and where the 
appropriate receiver is turned on. Conflicts are 
registered as invalid line status. The logical line 
mode is set to "inactive" and the other options are 
initialized. The connected line is assumed to be 
a dedicated line or a line that has already diaied- 
in. A user program can poll the lines with a 
"check status" order to determine when a line has 
been connected. 



M:COC FUNCTION 

Once the RCOC initialization routine has prepared the 
communication equipment, the status of each line is "dis- 
connected". All input and output are rejected until the 
line is connected. If the line is dedicated, only a "con- 
nect line" call to M:COC is required. If the line must be 
dialed-in (using M:IOEX), the dial operation must precede 
the "connect line" call to M:COC. The connect sets the 
line status to "inactive" (i.e. , available for I/O transfers). 
I/O operations are initialized sequentially, and when com- 
pleted, the line status is set to "message complete". At 
this point the line is still busy and can be cleared (i.e., 
set to "inactive") only by a call to M:COC to check the 
status of the previous operation (order 4). The call "check 
operation" is not required after a check status, a connect 
or a disconnect ooeration- A disconnect operation se ^s the 
line status to "disconnected", and the line must be recon- 
nected before it can be used again (see Appendix F). 
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5. I/O OPERATIONS 



BYTE-ORIENTED SYSTEM 

The Monitor performs all I/O services for the byte- 
oriented I/O system. This includes: 

Logical-to-physical device equivalencing. 

Initiating I/O requests. 

Standard error checking and recovery (optional). 

Software checking of background and Monitor. 

Software checking of background requests to preserve 
protection of foreground and Monitor. 

Optionally generating device order bytes for device- 
independent operations. 

Accepting user-generated IOCDs and device order 
bytes to provide complete control for a user's 
program. 

Using data chaining for foreground programs performing 
scatter-read or gather-write operations. 

Reading or punching cards in either BCD or 
EBCDIC. 

Positioning magnetic tapes and sequential RAD files. 

Editing from paper tape or keyboard/printer. 

All I/O interrupt handling. 

Managing both temporary and permanent RAD 
files. 

Limiting channel active time for I/O transfers. 

I/O INITIATION 

Whenever a task needs to initiate an I/O operation, it 
calls on the appropriate Monitor I/O routine (see Chap- 
ter 4 for complete calling sequences). These Monitor 
I/O routines are reentrant, so that a higher priority 
task may interrupt and request I/O during the initiation 
of a lower-priority task, in which case the low-priority 
task is suspended and the higher-priority task satisfied 
first. 



The channel time limits imposed by the Monitor on standard 
devices are as follows: 

Maximum Allowable Channel 



Device T 


ype 


Active 


Time 


(seconds) 


KP 






255 


LP 








3 


CR 








3 


CP 








3 


M9 








10 


PT 








820 


BR 








3 


BP 








3 


M7 








10 


RD 7202, 


7204 






3 


RD 7242 








4 


PL 






N( 


3t imposed 



END ACTION 

The chapter on Operator Communication specifies the pos- 
sible error messages. Generally, standard error recovery 
takes place when the I/O is checked for completion rather 
than on the I/O interrupt. This means that error recovery 
for the background will be processed at the priority level 
of the background rather than at the I/O interrupt priority 
level. However, there is a provision for the real-time fore- 
ground user to specify an end-action routine to be called 
when the Monitor answers the I/O interrupt. This is the 
AIO Receiver address in the I/O calling sequence, and it 
is to be used only when more sophisticated end-action is 
required or when a foreground task is to be restored to active 
status at channel end. The routine is processed at the priority 
level of the I/O interrupt, so the processing should be of 
very short duration. Reentrancy in this routine is the user's 
responsibility. For example, this routine might consist of 
storing the I/O status information and then triggering a 
lower-level external interrupt through a Write Direct, where 
this lower-level task performs the actual processing. The 
end-action routine should then return to the task from which 
it originally came (by RCPY L, P). 

The form of the call to the AIO Receiver is 



A real-time foreground program may acquire control of 
a multidevice controller from background users at the 
completion of any current I/O. This technique is used 
in place of queuing. All Monitor I/O initiation is made 
at the priority of the calling task, with background tasks 
having the lowest priority. 



LDA 

RCPYI 

B 



AIODSB 



P,L 



AIO Receiver address 



(device status byte 
from AIO in bits 0-7; 
device number in 
bits 8-15) 
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The AIO Receiver routine should return to the location 
contained in the L register on the entry. All registers are 
assumed to be volatile, which means that they need not be 
saved and restored to their former contents. 



The purpose of the AIO Receiver technique is to allow a 
real-time user program to be informed by RBM when chan- 
nel end occurs on a particular I/O operation. It is used 
instead of I/O queueing by the Monitor. Typically a fore- 
ground program wishing to maximize I/O and computation 
overlap will issue an I/O request with the no-wait option 
and with an AIO Receiver address specified. When the 
I/O is successfully initiated, the foreground task exits from 
the active state (by a call to M:EXIT) and is restored to 
active status at channel end by a Write Direct to trigger 
the interrupt level from the AIO Receiver. The foreground 
program must then return to the Monitor I/O routine with 
the "check" option to complete the end action on the 
file. See Chapter 6 for a more detailed discussion of 
AIO Receivers. 



Note: For transfers invoking blocked files where no 
I/O is actually performed, the X register will 
contain -1 to indicate that the AIO receiver 
will not be entered. 



Table 16. Standard Device Unit Numbers 



Device Unit 




Number 


Standard Assignment 


101 


Keyboard/printer input 


102 


Keyboard/printer output 


103 


Paper tape reader 


104 


Paper tape punch 


105 


Card reader 


106 


Card punch 


108 


Line printer 



Table 2 shows the standard background operational labels. 
The devices and functions shown indicate how the standard 
processors use these labels. Since each I/O call must specify 
a byte count, a user program can read any number of bytes 
from SI (if SI is magnetic tape, for example). The labels 
are merely a name. There is no restriction on the record 
size except as imposed by the peripheral devices. 



LOGICAL/PHYSICAL DEVICE EQUIVALENCE 

When writing a foreground or background program in 
either Symbol or FORTRAN, the user is not required to 
know the actual physical device number that will be 
used in the input/output operation. Two ways are pro- 
vided under RBM to help the user select the input/output 
device on a logical rather than physical basis. 



The first method is the direct logical reference. The user 
can specify a device-file number in his calling parameters 
to the input/output routines, and RBM will translate this 
into an actual physical device number. There may be 
several device-file numbers pointing to the same physical 
device; however, only one device-file number is generally 
needed per device per active task in the system. Each 
device-file number can be used by only one task at a time. 
This is a necessary restriction since the I/O status is saved 
in the device-file number table in theRBMand independent 
operation by several tasks on the same device would cause 
invalid status from the separate tasks using it. 

The second method is device referencing through indirect 
logical reference. This method first assigns a device unit 
number or an operational label to a device-file number, 
which in turn is assigned to a physical device number. The 
equivalence of operational labels or device unit numbers 
and the device-file numbers is set at System Generation 
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and 16. The standard assignments may be changed later by 
use of ! ASSIGN or {DEFINE control commands. 



RAD FILES 

The two types of RAD files available are sequential files 
and random files. A sequential file may be used like a 
single-file magnetic tape, whereas a random file may be 
used like a truly direct-access device. The capabilities 
and restrictions of each type of file are described below. 

Random and sequential files vary in two primary respects 

1. Sequential files cannot be accessed randomly; the next 
record to be accessed is the one at which the file hap- 
pens to be positioned. 

2. Sequential files can only be updated at the end. 



SEQUENTIAL FILES 

1. Sequential RAD files are available to foreground and 
background tasks. 

2. Sequential RAD files are available to routines M.-READ, 
M:WRITE, and MrCTRL, but not to M:IOEX. 

3. Sequential RAD files can be blocked (with more than 
one logical record per block) if the logical record size 
is less than or equal to half the RAD sector size. The 
Monitor I/O routines do the blocking and unblocking. 

4= Sequential RAD files con be compressed ^with blanks 
removed) if they are EBCDIC data. The Monitor I/O 
routines do the compressing and expanding but do not 
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check for binary data. Compressed records are always 
blocked and of variable size; therefore the logical 
record size has no meaning except when allocating 
the file. 



5. Logical records may be less than, equal to, or 
greater than the RAD sector size. Unblocked records 
always start on a sector boundary. Therefore, if a 
logical record is less than a RAD sector and is un- 
blocked, the remaining bytes of the sector will be 
ignored. If a logical record is greater than a sector, 
it will occupy an integral number of physical sectors 
and the remaining bytes of the last sector will be 
ignored. 

6. BOT (beginning-of-tape) is defined as the logical load- 
point and equals the first sector of the file. EOT is de- 
fined as the logical end-of-tape and equals the last 
sector +1 of the file. EOF (end-of-file) is defined as 
the logical file mark (which may or may not exist). 

7. As on magnetic tape, once a logical record orfilemark 
is written on a file, any records orfilemarks previously 
written beyond that point are unpredictable. 

8. Sequential RAD files (except compressed files) can be 
spaced forward or backward by logical records. 

9. Sequential RAD files can be positioned by ! REWIND, 
IFBACK, and IFSKIP commands. 

10. Sequential RAD files can request an AIO Receiver at 
channel end for physical I/O transfers. When oper- 
ations involve only logical I/O transfers, the AIO 
Receiver will be ignored. A flag will be set indicating 
whether the AIO Receiver is to be acknowledged or 
not, (see M:READ/M:WRITE status returns). 

11. RAD transfers must consist of an even number of 
bytes. 

12. Operational labels can be equated to permanent files 
on the RAD, or be allocated from available temporary 
RAD space. This can be accomplished either through 
control cards (for standard assignments) or through 
Monitor service calls at execution time for nonstandard 
assignments. 

13. When the operational label is defined or assigned to 
a permanent file, it is automatically positioned at 
the BOT. 

14. As on magnetic tape, the only record that can be 
written at the EOT is the logical file mark. 



RANDOM FILES 

1. Random files are available to foreground and back- 
ground jobs. 



2. Random files are available to routines M:READ and 
M:WRITE, but not to MrCTRL or M:IOEX. 

3. All unblocked I/O transfers start on a granule boundary 
within a file. These granule boundaries are addressed 
as a number that represents the displacement of the 
granule from the start of the file, beginning with zero. 
A granule boundary always begins on a sector boundary 
but need not end on one (see discussion of granules 
below). 

4. All positioning commands such as 1REWIND, IFSKIP, 
etc., are meaningless. 

5. The transfer of any number of bytes (to a maximum 
of 65,534) may be requested, provided that the byte 
count is an even number and the transfer will not ex- 
tend past the file boundary for unblocked files. For 
blocked files a single record is processed on each 
call. 

6. Operational labels can be equated to permanent files 
on the RAD or can be allocated from available tem- 
porary RAD space. This can be accomplished either 
through control commands (for standard assignments) or 
through Monitor service calls at execution time for 
nonstandard assignments. 

7. When a random file is defined, the user may specify 
a FORTRAN logical record size and a pointer to the 
word where the last referenced FORTRAN logical 
record +1 is stored. This information, although un- 
used by the Monitor, is stored in the file and may be 
requested by executing programs or processors (such as 
the FORTRAN compiler), if necessary. 

8. Random files may not be compressed. They may be 
blocked with transfer on a logical record basis. In 
this case, the Monitor performs all blocking/deblocking 
operations. Any Write operations are really an update 
in place and unmodified portions of a block are pre- 
served. A block is not read into core if it is already in 
core from a previous operation. 

9. BOT is defined as the first sector of the file. EOT is 
defined as the last sector +1 of the file. EOF has no 
meaning in random files except for file saving, truncat- 
ing, and mapping purposes. 

10. Requests for a foreground AIO Receiver at channel end 
will always be acknowledged. 

11. Random files (either blocked or unblocked) may be 
accessed sequentially or randomly. At the end of any 
operation, RBM automatically updates the record dis- 
placement pointer to the "next" record. The pointer 
can be "set" by any random operation, and is initially 
set to the beginning of the file. 

As much data as specified by the byte count will be 
transferred for the unblocked random files but only one 
record at a time will be transferred for blocked random 
files and incorrect length can occur. 
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GRANULES 

While a granule is usually synonymous with a sector on a 
device, it may be defined (on a file basis) to be equivalent 
to any of the following: 

• A partial sector. 

• One sector. 

• Several sectors. 

A granule always begins on a sector boundary but need 
not end on such a boundary. For example, to make the 
7204 RAD and the 7242 disk pack transfers equivalent, a 
granule can be defined to be 1024 bytes; this is then one 
sector on the disk pack and two sectors plus a fraction of 
a sector on the 7204 RAD. 



RAD FILE MANAGEMENT 

RBM permits allocation of the RAD into the subsections 
shown in Figure 4. The exact bounds on these sections are 
computed from the size of required contents or selected by 
the user in accordance with the anticipated use of the 
system. In either case, the bounds are set during System 
Generation, and cannot be changed except, by a new 
System Generation. RBM maintains directories for as many 
areas as the user specifies up to 15, plus: the System 
Library, System Processor area, and System Data area. RBM 
also maintains control of the checkpoint area. The back- 
ground temporary space is allocated from control command 
inputs or from calls to M:DEFINE as requested. 

Areas need not be allocated contiguously (RAD tracks may 
be skipped between areas), and can be distributed over 
more than one RAD. One to 16 areas may be allocated on 
each RAD or disk pack- However, each area must exist en- 
tirely on a single RAD. If there is more than one RAD on 
the system, one will be designated as the RBM System RAD, 
which will receive any default areas. Any RAD with sec- 
tor available will receive a bootstrap in that area. 











RBM Bootstrap Loader 




System Processor area 


System Library area 


System Data area 

RBMGO RBMAL 
RBMOV RBMS2 
RBMPMD RBMSYM 
RBMID 


User Processor area 


User Library area 


User Data area 


Checkpoint area 


Background temporary storage 


aa areas 


Alternate tracks (disk pack only) 









Figure 4. RAD Allocation 
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6. REAL-TIME PROGRAMMING 



FOREGROUND PROGRAMS 

Under the Sigma 2/3 RBM, a foreground program is one that 
operates in protected memory, utilizes foreground opera- 
tional labels or device unit numbers, and has access to 
privileged Sigma 2/3 instructions. It is protected from any 
background interference through an integrated hardware/ 
software protection scheme. A foreground program may be 
classified as either a resident foreground program, a semi- 
resident foreground program, or a nonresident foreground 
program, and it it important that this distinction be 
understood. 

RESIDENT FOREGROUND PROGRAM 

Foreground programs are defined as resident through the 
RAD Editor when their files are created on the user pro- 
cessor area of the RAD. They are loaded into core from 
the RAD whenever the RBM system is booted, and are either 
automatically armed, enabled and (optionally) triggered, 
or they initialize themselves through their own initializa- 
tion routines. Once loaded into core for execution, resi- 
dent foreground programs remain resident until the RBM 
system is again booted from the RAD. 

SEMIRESIDENT FOREGROUND PROGRAM 

Semiresident foreground programs are normally not in core 
memory. They are not read into core when the RBM system 
is booted but must be called in explicitly when needed. 
Semiresident foreground programs, when loaded, reside in 
the resident foreground area. The user must schedule the 
loading of semiresident foreground programs because the 
Monitor provides no protection against overlay or over- 
loading. When loaded, they may be automatically armed, 
enabled and (optionally) triggered, or they may initialize 
themselves through their own initialization routines. 

NONRESIDENT FOREGROUND PROGRAMS 

Nonresident foreground programs are normally not in core 
memory. They are not read into core when the RBM system 
is booted but must be called in explicitly when needed. 
Nonresident foreground programs, when loaded, reside in 
the nonresident foreground area, and the area is then consid- 
ered "active" and is not available for subsequent use by other 
programs (including the Monitor) until the program occupying 
this area releases it by "unloading". This feature is useful 
when a system has several nonresident foreground programs 
that have a resource allocation problem or are connected to 
the same interrupt level. The Monitor will control access 
to the nonresident foreground area, thus providing protec- 
tion against multiple loading of these conflicting programs. 

If nonresident programs are to be used, at least six cells 
must be allocated for the nonresident foreground area of 
core. If allocated, the nonresident foreground area is 



adjacent to the background. If a nonresident foreground 
program is to be loaded and the length of the longest path 
(including COMMON) exceeds the size of the nonresident 
foreground area, the background is automatically check- 
pointed to allow the program to extend to the background. 
The background remains checkpointed until the nonresident 
foreground program unloads by a call to M:LOAD. When 
loaded, nonresident foreground programs may be automati- 
cally armed, enabled and (optionally) triggered; or they 
may initialize themselves through their own initialization 
routines. 

MONITOR TASKS 

The relative priorities of the separate Monitor tasks are 
given in descending order below: 

Highest Counters (optional) 

Power On Task 

Power Off Task 

Machine Fault (Memory Parity Error) Task 

Protection Violation Task 

Multiply Exception Task (optional) 

Divide Exception Task (optional) 

Input/Output Task 

Control Panel Task 

Counters = (optional) 

Real-Time Task(s), if any lower than I/O 

RBM Control Task (lowest hardware level) 

Background (lower than all hardware levels) 

Although the tasks are not reentrant, they are serially 
reusable; that is, as soon as a task finishes processing one 
request, it can immediately process another. For example, 
I/O interrupts are processed one at a time, with the highest 
priority device always processed first if several interrupts 
are waiting, but as soon as the processing of one interrupt 
request has been completed, another request for a separate 
device can be processed. 

POWER ON TASK 

The Power On Task performs the following operations: 

• Waits for acceptable RAD status. 

• Arms and enables all RBM interrupts. 
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• Sends a ! ! POWER ON message. 

• Restores protection registers to failure-time contents. 

• Loads and links to the Power-On Receiver if specified 
in mailbox location X'C4'. 

• Restores status at Power-Off time and exits if the com- 
puter is a Sigma 3 with no external interrupts and there 
are no critical tasks. 

• Restores context and exits if it is a Sigma 2 or there are 
external interrupts or critical tasks and background 

is active. 

If none of the above conditions are satisfied, the background 
is aborted, the Power-On interrupt is cleared and a crash 
is forced. 



POWER OFF TASK 

The Power Off Task performs the following operations: 

• Saves the internal interrupt status. 

• Saves context via a call to M:SAVE. 

• Scans the Channel Status Table and issues an HIO to 
any channel flagged active and saves the device status 
byte and the even and odd channel register contents in 
the File Control Table. 

• Interrogates foreground mailbox X'C3' for a power-off 
receiver. If one is specified, a branch is made to it; 
otherwise, the Power Off Task waits for the power-on 
interrupt. 



Since Power-On processing is installation dependent and 
correct recovery cannot always be guaranteed, a user- 
developed Power-On Receiver must be used to restart after 
a power failure. The following action may be taken within 
the receiver: 

1. Timeout errors will be simulated on all active I/O 
channels at Power-Off time. Code within the receivers 
may restart I/O for these devices. 

2. The interrupt status is determined, in general, through 
the TCB chain (each TCB contains the address of theTCB 
of the task it interrupted). Race conditions can exist 
that may cause this chain to inaccurately reflect the 
interrupt status, although the PSD chain is correct. If 
this risk is considered negligible or the effects unharm- 
ful, the tasks can be reactivated through the TCB chain 
by the receiver, 

3. The foreground Power-On Receiver may activate one or 
more foreground tasks or take other special action to 



restart the system. This may involve going to some 
recent checkpoint. 

4. The receiver may exit frorr the Power-On routine by 
going to M:EXIT. 



MACHINE FAULT TASK 

This task responds to the following Machine Fault conditions, 
in order of priority. 

1. Memory parity Error 

2. External IOP timeout 

3. Incorrect direct I/O 

4. Internal' IOP timeout 

5. Combination of conditions 2 or 3 and 4. 

Of these conditions background can only cause a memory 
parity error. When this occurs, the Machine Fault Interrupt 
(MFI) task triggers RBM and the background task is aborted 
with an error code of PE. For all of the above conditions, 
including parity error when background is not active, an 
appropriate foreground receiver will be tested, as specified 
below. If this receiver pointer is zero, the action specified 
below will betaken. Otherwise, the receiver will be 
linked to via a RCPYI P, L. If the receiver returns, the MFI 
task will proceed as if a receiver was not specified. The 
receiver may correct the situation and simply call M:EXIT. 

Receiver A A . T , T 

Active I ask lype 



Pointer 
Condition Address Critical 



Non Critical 



X 'IAD' Crash, code = PE Abort code = PE 

X 'TAB' Crash, code = E7 Crash, code = ET 

X ! 1AA ! Crash, code = MF Abort, code=MF 

X ' 1AO Machine Fault Machine Fault 
Message Message 



Abort action consists of disabling the associated interrupt 
and exiting the task. If the task occupies the Non Resident 
area, an UNLOAD will be performed. If an HOP time- 
out occurs, RBM will be triggered to write the "Machine 
Fault ..." message. The active task will not be terminated 
but, on exit from the MFI task, overflow and carry will be 
set to indicate device not recognized. 

All foreground abort messages and the "Machine Fault ..." 
message will be written at the RBM Control Task level. 
Therefore, if two consecutive foreground tasks abort, only 
the message for the lower priority task will appear. How- 
ever, both a foreground abort message and the "Machine 
Fault ..." message may accumulate. 

PROTECTION VIOLATION TASK 

Any attempt by the background to modify the contents of 
protected memory, or to execute a privileged instruction, 
will cause the Protection Violation Task to abort the back- 
ground program, using the same method as the Memory 
Parity Task. 
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Unavailable core is set "protected. Write attempts to un- 
available core cause protection errors, and read attempts 
from unavailable core cause parity errors. The abort code 
after a protection error shows the location causing the error 
if the error was an invalid store or a privileged instruction. 
An attempt by the background to branch to protected mem- 
ory will cause an abort with the address of the location that 
was being branched to. Note that Monitor service routine 
calls actually cause a protection violation from the back- 
ground. However, if the branch address and the return to 
the background are valid, the branch is permitted. 

The set multiple precision mode instruction, RD X'8T, does 
not cause a protection violation when multiple precision 
hardware is implemented. 



a foreground disable and abort may occur (see "Operator 
Control", Chapter 3). Otherwise, the Control Panel Task 
sets the key-in flag for the RBM Control Task, triggers the 
RBM Control Task and exits. The key-in operation itself is 
performed at the level of the RBM Control Task. 



RBM CONTROL TASK 

This task controls unsolicited key-ins and background oper- 
ations. It is the only RBM task that actually performs input/ 
output and, therefore, is the only task that requires tempor- 
ary stack space for the reentrant RBM input/output routines. 



MULTIPLY/DIVIDE EXCEPTION TASKS 

These tasks simulate and subsequently execute a Multiply or 
Divide instruction for Sigma 2/3 computers not equipped 
with Multiply/Divide hardware. They are not reentrant, 
and all lower interrupts are essentially locked out for the 
duration of the simulation (approximately 250 to 300 CPU 
microseconds. ) 

INPUT/OUTPUT TASK 

After an input/output interrupt, the Input/Output Task . 
identifies the highest priority device with a pending 
interrupt. It then clears the channel activity status and 
sets the operational status byte count residue in the proper 
device-file status table, if the device is no longer opera- 
ting. (The channel is not cleared for a zero-byte-count 
interrupt.) If a foreground AIO Receiver was specified (for 
a description of an AIO Receiver, see "I/O Operations" in 
Chapter 5), control is transferred to this receiver at the 
I/O priority level. It is expected that the AIO Receiver 
exit properly. 



SCHEDULING RESIDENT FOREGROUND TASKS 

When several different programs and tasks are simultanously 
located in core memory, scheduling is required for the 
orderly transfer of control from one task to another. Sched- 
uling takes place in accordance with the following rules: 

1. When no background or foreground task is active in 
the system, the Monitor enters the "idle" state until 
the operator directs the loading of a set of control 
commands from an input device. 

2. After a background program is loaded, the Monitor 
transfers control to the program by an exit sequence 
from the RBM Control Task. During execution of the 
background program (if the program is waiting for its 
own I/O to complete), there can be nothing else in 
execution in the system. That is, the Monitor makes 
no attempt to multiprogram to absorb idle time. If 
there is an armed and enabled resident foreground task 
in core, the foreground program may receive an inter- 
rupt from some external source. 



To minimize interrupt inhibit time, the channel registers 
are loaded and the I/O initiating SIO is issued at the I/O 
interrupt priority level. Consequently, any task with a 
priority level higher than I/O must not use M:READ, 
M:WRITE, or M:IOEX to perform I/O, but may perform 
its own I/O without interrupts. 



When Clock 1 is employed (a SYSGEN option), MrREAD/ 
M:WRITE operations are subject to a time limit. Clock 1 is 
used to ensure that no channel is active beyond a preset 
limit. If the limit is exceeded, an HIO is issued to the 
offending device and appropriate end action will be taken. 



CONTROL PANEL TASK 

A Control Panel Interrupt causes the Control Panel Task to 
perform one of two functions: (1) to remove the foreground 
task, (2) notify the control task of a pending key-in. 
If the Control Panel data switches are set appropriately, 



3. After entry, the interrupting task saves the contents of 
any registers it will alter and proceeds to carry out its 
function. The task may use either the M:SAVE service 
routine to perform the saving opertions or it may save 
the contents of the registers itself. 

4. When the real-time task is completed, it may restore 
the context of the interrupted task and exit via the 
standard Sigma 2/3 exit procedure or may have these 
functions performed by the M:EXIT service routine. 



Warning: If the real-time task has changed the state 

of the interrupt levels by arming or disarming 
any active interrupt, the system integrity 
will be lost. The enable/disable feature 
should be used to prevent interrupts until an 
orderly exit and inactive state is achieved. 

Note that this is a last-in, first-out form of scheduling. 
The interrupting task may itself be interrupted at any time 
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during execution by a higher priority task, up to the maxi- 
mum possible number of tasks in the system. 

Each time, a new task saves the status and register contents 
of the interrupted task. When the new task exits, control 
is returned automatically to the task it interrupted. If there 
is another interrupt waiting between the level of the current 
task (which is just completing) and the interrupted task, the 
originally interrupted task is immediately interrupted again 
and the new (intermediate) task follows the same procedure. 
Thus, it is never necessary for any task to know what task 
precedes or follows it. The task merely preserves and re- 
stores the environment according to the established rules. 

The design of the hardware priority system makes it unneces- 
sary for the Monitor to be involved in the actual schedui- 



sng, 



rogr 



independently control the execution priority of certain 
operations within the foreground. For example, a real-time 
foreground task that is activated by an external interrupt 
may perform some processing and then issue a special Write 
Direct to trigger another related task to continue the pro- 
cessing at a higher or lower interrupt level. If the Write 
Direct is to a higher level, the interrupt to the higher level 
takes place immediately and the new task is begun. More 
frequently, the Write Direct is to a task at a lower priority 
level, and in this case the current task exits in a normal 
manner and the highest priority "waiting" task will become 
active. This task may or may not be the one that just re- 
ceived the Write Direct. Eventually, the task that re- 
ceived the Write Direct will be reached, and this task will 
then continue the processing at that level. Thus, real-time 
foreground programs can have an intricate scheduling scheme 
with no RBM intervention. 



Another method of loading a foreground program is through 
an unsolicited key-in by the operator. The operator must 
generate a Control Panel Interrupt and, in response to the 
request IKEYIN, type is "Q name", where "name" must 
be the name of a foreground program residing in the user 
processor area of the RAD. This action results in a call to 
MrLOAD to queue the request. This method could be used 
in response to conditions detected outside the computer sys- 
tem (e.g., a certain time of day). Both the above methods 
apply to semiresident as well as nonresident foreground pro- 
grams. For resident foreground programs, they would be 
used only to obtain a fresh copy of a particular program 
without rebooting the entire system. 

Loading through use of the queue stack requires use of the 
nonresident foreground area whether or not the request is to 
be loaded into this area. Therefore, whenevera nonresident 
foreground program is loaded, all queue stack loading is 
suspended until the program occupying the nonresident fore- 
ground area releases the area by unloading. 

Two other methods of loading foreground programs are avail- 
able. They involve control commands normally used by the 
background, are part of a background job stack, and must 
be preceded by an FG key-in. These commands are 

!XEQ initiates loading from whatever RAD file to 

which background operational label OV is assigned. 
The method presumes that either the appropri- 
ate OV oplb assignment has been made, or that 
the program to be loaded is on the RAD file 
RBMOV to which the label OV is assigned by 
default. 



An example of interrupt-d riven scheduling is illustrated in 
Figure 5. 



LOADING FOREGROUND PROGRAMS 

Foreground programs may be loaded into core for execution 
in any of several ways. All programs mustreside ontheRAD 
to be read into core memory for execution. They must be 
written onto the RAD by the Overlay Loader or the Absolute 
Loader. (See the !ABS control command description in 
Chapter 2 for restrictions regarding the use of the Absolute 
Loader. ) In each of the methods described below, only 
the root is loaded into memory as a result of the action 
taken. Segments must be read in by subsequent calls to 
MrSEGLD. 

The most common method of loading a foreground program is 
through a call to MrLOAD by another foreground program. 
The call takes place at the priority level of the foreground 
program and the request is placed into the queue stack. The 
program is actually loaded by the Monitor subroutine 
S:LOAD at the level of the RBM Control Task, and this 
method is the most logical one to be used. It is based upon 
conditions automatically detected by other foreground pro- 
gramsand requires no response or assistance from the operator. 



Sname causes the foreground program "name" to be 

loaded in the same way a background processor 
is loaded. The foreground program must reside in 
eithertheSP, FP, orUParea: they will be searched 
in that order. The user is responsible for avoiding 
the duplication of program names. 

The control command methods are closely tied to back- 
ground schedules and do not provide adequate response to 
real-time needs. However, they can be used when de- 
bugging foreground programs. 



LOADING RESIDENT FOREGROUND PROGRAMS 

Loading of real-time programs into their predefined RAD 
files can be accomplished by the Absolute Loader from the 
background job stack, or resident foreground programs can 
be written into their predefined RAD files by the Overlay 
Loader. It is not necessary to create the foreground pro- 
grams when the system is created. However, to get the 
foreground program in absolute form will require either the 
use of the Overlay Loader or that the job be assembled in 
absolute as a self-contained package. 



66 Loading Foreground Programs 



High 



I/O INTERRUPT 



I/O AIO rcvr(2) 

11 



FGND 1 



Request CHECKPOINT 



1 r -! 1 : 

I I I 



Request RESTART 

J. 



Initiate I/O (AIO rcvr) 



FGND 2 



2 : 



FGND 3 



E 



■i 3 



'BKG RESTART' 



RBM CONTROL TASK 



CKPT CKPTrcvr(l) 



'BKG CKPT' 



b 



BACKGROUND 



BKGNDH 
i 



!BGh 



iBKGND 



TO TI 



TIME SEQUENCE 



Time Point Activity (Meaning) 



T2 T3 T4 T5 T6 T7 T8 T9 T10 Til 
Note: Times need not be equally spaced. 



TO The background is executing. 

Tl An interrupt is received for Foreground Task 2 which becomes active and saves the environment of the 

interrupted background task into its TCB. 

T2 Foreground Task 2 requests an I/O operation, specifies an AIO Receiver, and exits. The background 

resumes processing. 

T2.5 An interrupt is received for Foreground Task 3 which interrupts the BG. 

T3 An interrupt is received for Foreground Task 1 which becomes active and saves the environment of the 

interrupted task (Task 3) into its TCB. 

T4 At channel end, an I/O interrupt is received for the operation initiated by Foreground Task 2; the 

I/O Interrupt Task saves the environment of the interrupted task (Task 1). The AIO Receiver is 
entered at the I/O interrupt level and triggers Task 2, indicated by dotted line at FGND 2 level. 



Figure 5. Foreground Priority Levels 
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Time Point Activity (Meaning) 



T5 



T6 



T7 



T8 



T9 



T10 



Til 



The AIO Receiver returns via a RCPY L,P instruction. The I/O Interrupt Task exits, restoring the 
interrupted task's status. Foreground Task 1 resumes operation, requests a checkpoint of the back- 
ground, and specifies a Checkpoint Complete Receiver. This action causes the RBM Control Task 
to be triggered, indicated by broken line at RBM Control Task level. 



Foreground Task 1 exits, restoring the interrupted task's status, 
is waiting and it immediately becomes active. 



This was actually Task 3, but Task 2 



Foreground Task 2 exits, restoring the interrupted task's status. This was Task 3. It becomes active 
and continues from where it was suspended. 

Foreground Task 3 exits, restoring the interrupted taks's status. This was actually the background 
task. Since the RBM Control Task was triggered at 15, it is the highest waiting interrupt level. The 
RBM Control Task becomes active and stores the interrupted task's status into its TCB. The RBM 
Control Task calls the RBM subtask SrCKPT which writes the background into the RBM Checkpoint 
area on the RAD. S:CKPT then extends memory protection to the background and enters the specified 
Checkpoint Complete Receiver at the RBM Control Task level. In this illustration the Checkpoint 
Complete Receiver triggers Foreground Task 1 with a Write Direct instruction. 

Foreground Task 1 becomes active and saves the environment of the interrupted task in its TCB. The 
background area is now available to Foreground Task 1 for instructions and/or data. When processing 
is complete, Foreground Task 1 requests a restart. 

Foreground Task 1 exits, restoring the interrupted task's status (in the Checkpoint Receiver, which 
returns via a RCPY L,P instruction). The RBM subtask SrCKPT now completes its operation and 
returns to the RBM Control Task which calls in the subtask SrREST to restart the background task. 
S:REST first clears the background area, then reads the checkpointed background task in from the 
RAD. The background is then set "unprotected" which completes the restart operation. 

The RBM Control Task exits, restoring the status of the interrupted background task which then 
resumes processing. 



Figure 5. Foreground Priority Levels (cont. ) 



LOADING NONRESIDENT FOREGROUND PROGRAMS 

Nonresident foreground programs are loaded by the Monitor 
service routine M:LOAD. Once loaded, these programs 
can be connected to an interrupt via an initialization rou- 
tine or else can be triggered by a code given in the pro- 
gram's TCB. These programs then behave exactly like 
resident foreground programs. If the program just loaded 
resides in the area of core referred to as the nonresident 
foreground area, the nonresident foreground area is tied up 
until the program releases this space. Ordinarily, a pro- 
gram releases space by a call to MrLOAD to "unload". 
However, a FORTRAN program has no means of performing 
this unload except by calling a special library routine. A 
method is provided to automatically unload this area when 
MrABORT or MrTERM is called by the task occupying 
the nonresident foreground area. Therefore, a FORTRAN 
program calis the library routine L:OP (generated by the 
compiler when the program calls STOP) to terminate and 
unload. If a FORTRAN program calls EXIT, the nonresident 
foreground area will not be unloaded. 



FOREGROUND INITIALIZATION 

When a foreground program is loaded, it may either be 
initialized by RBM (see Overlay Loader options in Chapter 7) 
ormay have its own initialization routine (coded in assembly 
language). If the header of the foreground program contains 
a transfer address (as indicated by the END statement in the 
program source), RBM honors this address as the entry point 
to an initialization routine, and it is not mandatory that 
the program begin with a TCB. This routine may arm and 
enable (or whatever) one or a number of related real-time 
interrupts. It can also set RAD files for subsequent use and 
set up initial values in core data tables. The initialization 
routine runs at the priority level of the RBM Control Task 
with the privileges of a foreground program. The initializa- 
tion routine should make no calls on routines requiring tem- 
porary storage, since the RBM temp stack is the one in use. 
When foreground initialization is completed, the routine 
returns to RBM via a register copy of L to P. Foreground 
initialization routines will also be executed any time the 
system is rebooted from the RAD. 



68 Foreground Initialization 



90 10 37F- 1(3/72) 



TASK CONTROL BLOCK FUNCTIONS 

The Task Control Block (TCB) is a convenient means for 
organizing and storing information necessary to attain pro- 
per context switching, define dynamic blocking buffer 
pools, define temporary space necessary for reentrancy, 
and arm and enable the associated task. A foreground 
program may have one or more TCBs within the program 
(one for each task), but it is assumed that the first 
loadable item within a foreground program is a TCB. The 
TCB is used by the Monitor service routines M:SAVE, 
M:EXIT, M:LOAD, and by the Control Command Inter- 
preter upon encountering a !C: command. 



The TCB consists of 17 words and can be created at assembly 
time with Extended Symbol, or at load time by the Overlay 
Loader. (A FORTRAN program must have its TCB created 
by the Overlay Loader). The TCB is usually a block of 
code contiguous to the task it describes, withaddress literals 
pointing to the temporary stack space. A DATA statement 
can set the initial code for the interrupt level state for the 
task interrupt level. The complete contents of the TCB 
are shown in Table 17. 



Bit T in word TCB + 1 indicates whether the task is using 
the Monitor I/O routines and the floating accumulator; if 
bit T is zero, a temporary stack is required and the MrSAVE 
routine will initialize locations 0001 through 0006, after 
saving the previous pointers for the interrupted task. If 
bit T is a 1 (meaning no floating accumulator and no 
temporary space are required), the MrSAVE routine will 
not set these locations. In a real-time environment it is 
recommended that a user does not set the T bit to 1 (the 
floating accumulator and temporary storage pointers are 
saved). The Monitor service routines MrSAVE and MrEXIT 
do not, themselves, use any temporary storage. 

When the task is programmed in FORTRAN, the task en- 
trance and exit, TCB, and task entrance procedure are set 
up by the Overlay Loader. The module load routine 
MrLOAD sets the pointer to the PSD into the dedicated 
interrupt location and arms, enables, and optionally triggers 
the associated interrupt level. 

The background program will have a Task Control Block in 
protected foreground space. 



Note: The code in TCB + 2 is the exact code used in the 

Write Direct that sets the interrupt level. This code 
is described in the Sigma 2 and Sigma 3 Computer 
Reference Manuals under "Interrupt System Control. 



Cautionr Locations 1 through 5 in the zero table are not 
saved and are recreated from location 6. Thus, 
locations 1 through 5 must not be changed by 
a foreground program or they will not be the 
same after interrupt has taken place. 



Table 17. Task Control Block (TCB) 



Location 


Contents 


Set by 


TCB+0 


ADRL PSD 


Assembler/Loader 


1 


0-3 


4 


5 


6 


7 


15 


Assembler/Loader 


R-bit No. 
For WD 


T 


C 


X 


Dedicated Interrupt Location 


2 


3 


4 


5 7 


8 11 


12 


15 


Assembler/Loader 


0001 





Code 


0000 


Int. Group 


No. 


3 


ADRL TEMPBASE (temporary stack) (FWA) 


Assembler/ Loader 


4 


ADRL TEMPLIM (temporary stack) (LWA+1) 


Assembler/Loader 


5 


Contents of L register from interrupted task 


Current task (on actual entry) 


6 


Contents of T register from interrupted task 


MrSAVE (or current task) 


7 


Contents of X register from interrupted task 


MrSAVE (or current task) 


8 


Contents of B register from interrupted task 


MrSAVE (or current task) 


9 


Contents of E register from interrupted task 


MrSAVE (or current task) 


10 


Contents of A register from interrupted task 


Current task (on actual entry) 


11 


Contents of location 0006 (KrBASE) from interrupted task 


MrSAVE 
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Table 17. Task Control Block (TCB) (cont.) 



Location 


Contents 


Set by 


12 


Contents of Location 0007 (K:TCB) from interrupted 
task. 


M:SAVE 


13 


Dynamic base (K:DYN) for temp of current task; 
initially TEMPBASE+6. 


Assembler/Loader (changed by M:RES and M:POP) 


14 


Buffer pool LEA +1 . 


Assembler/Loader 


15 


Bits 11-15 contain number of buffers (0 < n < 16) . 
Bits 0-10 are reserved for Monitor use and should 
be coded as zeros. 


Assembl er/Loader 


16 


"Use" bits for buffers in pool (0 if unused). 


M:OPEN or M:CLOSE 


PSD + 


Interrupt task status flags. 


Interrupt sequence 


1 


Interrupted task P register. 


Interrupt sequence 


2 


First instruction of current task. 

Remainder of program (The PSD must be contiguous 
with the program but need not be contiguous with 
the TCB.) 


Assembler/Loader 


where 




ADRL PSD is the Program Status Doubleword. It is the location shown in the dedicated interrupt location when 
the interrupt takes place. 


R— bit No. for WD is the hexadecimal value (from to F) that indicates the register bit that identifies the 
particular interrupt level within the Interrupt Group (the hardware block of 16 possible interrupts). 


T 


is the flag that indicates whether the M:SAVE and MrEXIT routines should set location 0001 to 0007; 
means yes, 1 means no. (T must be if any Monitor service routines are used. ) 


C 


is the flag that indicates whether the task is critical; means no, 1 means yes. The default value is 0. 


X 


indicates whether or not the task is to be triggered at load time: 1 means yes, means no. A code of 7 
is issued subsequent to issuing the code (normally 2, "Arm and Enable") given in word 2. 


Coc 


le is the interrupt system control code that indicates current or desired initial interrupt control status. The 
codes are 1 = disarm, 2 = arm and enable, 3 = arm and disable, 4 = enable, and 5 = disable. 


Buf 


: er pool is an amount of space from one to 16 buffer areas in length, each of which is equal in size to the 
value contained in K:BLOCK. 


"Us 


e" bits are bits, from left to right, beginning with zero, showing which of the maximum number of buffers 
nave been allocated by M:OPEN and have not yet been closed by M:CLOSE. 
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When the Overlay Loader creates the TCB for a foreground 
task, the items shown in Figure 6 are generated adjacent 
to the task. If the transfer address given in the object 
deck is relocatable 0, it is not treated as the entry point 
to an initialization routine, but is used as the entry address 
for that task. The task will be armed, enabled, and pos- 
sibly triggered when loaded for execution depending on the 
contents of words 1 and 2 of the TCB, supplied to the 
Overlay Loader on the ! $TCB card. 

After a foreground program is loaded into core, certain 
items in the TCB are examined. A fatal load error results 
if the number of specified operational labels requiring 
blocking buffers exceeds the number of available block- 
ing buffers (word 15 of TCB). If the number of available 
blocking buffers is sufficient, word 15 of the TCB is adjusted 
to reflect the current blocking buffer requirements. 

In the event of a fatal load error in response to a load re- 
quest from a background job stack via an !XEQ or Iname 
command, the following message is printed on the DO: 



! 1BKGD XE ABORT LOCATION FFFF 



If the request came from a queue stack load, the following 
message is logged on the DO: 



NONRES FGND PGM xxxxxxxx LOAD ERROR 



If a program has an initialization routine (that is, an end 
transfer address other than absolute or relocatable 0), that 
routine is responsible for storing word of the TCB (the 
address to receive the interrupted task's PSD) into the 
dedicated interrupt location, as well as arming and enabl- 
ing the appropriate interrupt level for each task within 
the program. 

The initialization routine may also be used to assign any 
specific operational labels required by the program (e.g., 
the operational label or device unit number required) to 
read in subsequent segments. 

If the program has no initialization routine, word of the 
first loaded task (actually word of that task's TCB) will 
be stored into the dedicated interrupt location for that task 
when the program is loaded. Next, the associated inter- 
rupt level is disarmed to remove any waiting interrupts; 
then it is armed, enabled, and possibly triggered, depending 
on the contents of words 1 and 2 of the TCB. 

When a foreground task is activated, control is transferred 
to the address given in the dedicated interrupt location, 
where the interrupted task's PSD is stored, and execution 
resumes at PSD+2 at the level of that foreground program. 
This is a hardware function that preserves the interrupt 
status and execution location of the interrupted task. Next 
the register contents of the interrupted task must be saved. 

Normally, the first instruction in a foreground program will 
store the contents of the accumulator into word 10 and the 
contents of the L register into word 5 of its TCB and then go 



to the Monitor service routine M:SAVE which will store the 
remaining register's contents into the active task's TCB. 
M:SAVE will also store the contents of K:TCB (used exten- 
sively by the Monitor to identify the currently active task) 
into word 12 of the TCB, and set K-.TCB to point to the 
active task's TCB. If the active task requires temporary 
storage (word 1, T=0), the contents of K:BASE are stored 
into word 11 of the TCB and K:BASE is set to the first word 
address of the active task's temp stack. The floating ac- 
accumulator is then set to point to the first six cells of 
the active task's temporary storage. 

When the currently active task has completed all its opera- 
tions, it exits through the Monitor service routine M:EXIT 
which restores the general register's contents and resets 
K:TCBand, if applicable, K:BASE. M: EXIT also performs 
a hardware exit sequence, by which it restores the interrupt 
status and the overflow and carry indicators, and returns 
to the interrupt task. 



FOREGROUND PRIORITY LEVELS AND I/O PRIORITY 

All foreground tasks with a priority level lower than the 
I/O priority level and operated without interrupts inhibited 
may use the Monitor I/O routines without any special re- 
strictions. However, foreground tasks that have interrupts 
or have an interrupt level higher than the I/O priority level 
level must not use Monitor I/O. 

The recommended procedure for a task whose interrupt level 
is higher than the I/O priority level is to trigger a task 
whose priority is lower than the I/O priority. This lower 
priority task would then perform the required I/O opera- 
tions. Generally, these high-level tasks are for emergency 
situations where no I/O is performed or when the task does 
its own I/O due to special requirements. 



AIO RECEIVERS 

An AIO Receiver is a means whereby a foreground program 
can initiate an I/O operation, release control to lower 
level tasks, and regain control when the I/O operation is 
completed. The AIO Receiver itself is a closed subroutine 
which operates at channel end (or zero byte count, if 
specified) at the priority level of the I/O interrupt. It is 
used in conjunction with an I/O operation specifying 
"initiate only and return" (no wait). Typically, in order 
to maximize compute and I/O overlay, the foreground pro- 
gram will issue an I/O request with the "no wait" option 
and specify an AIO Receiver. When the I/O operation is 
successfully initiated, this foreground task exits from the 
active state (by a call to M:EXIT) and is restored to the 
active status at channel end by a Write Direct to trigger 
the interrupt level (from its AIO Receiver). The next I/O 
operation for that device file-number must be a "check" 
operation to complete the end-action of the file. 

For I/O to RAD files, the AIO receiver may be activated 
before the operation is actually complete. This will happen 
whenever a transfer across a track boundary occurs, more 
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TEMP BASE 



n-word 





-fc-\A/rti-<-i n 


Reserved Area 




R 


ADRL Word n 




1 

2 

3 

4 
5 

12 

13 
14 

15 

Word 16 




~ Interrupt Information 







TEMPBASE 




TEMPLIM 








K:DYN (Dynamic Temp Pointer) 




Buffer Pool LWA+1 




No. Available Buffers 


Fnd of TCB 


Use Bits 




Word n 
ENTRY 


PSD Reserve 







STA 


TCB+10 




RCPY 


L,A 




STA 


TCB + 5 




RCPYI 


P,L 




B 


M:SAVE 




ADRL 


TCB 




B 


* $+ 1 




ADRL 


ENTRY 




Foregrou 


nd Task 





= exloc, specified on 
!$ROOTcard. 

n = temp, specified on 
! $ROOT card; first five 
words of temp are float- 
ing accumulator; sixth 
word is used by FIO. 



TEMP LIM 

Supplied on !$TCB card. 

Temp Stack FWA. 
Temp Stack LWA + 1 . 

Reserve for saving con- 
text of interrupt task. 

Initially set to 
TEMPBASE + 6. 

Set to Common Base. 

Common Base — Last 
Loaded item/K:SEC. 

Initially set to zero. 

Two-word reserve that 
" receives the interrupted 
task's PSD. 



Code to save registers, 
" TCB pointers, and temp 
pointers. 



Transfer Address 



Figure 6. Task Entrance Format 
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than X'lFFF' bytes are requested, or a bad track is en- 
countered. The calling task (not the AIO receiver) must 
issue a "check" operation to complete the transfer. An AIO 
receiverspecified forthe "check" operation, will be honored. 

Special considerations for use of AIO Receivers are: 

1. The operation requesting an AIO Receiver is an 
"initiate and return" operation. If the device or the 
file is busy, the I/O operation is not initiated and a 
busy status is returned. It is the user's responsibility 
to determine the course of action to be taken at this 
point (e.g., loop until ready or ignore the operation). 

2. If the file being used is a blocked file, an actual I/O 
operation may not be required, hence no channel end 
interrupt and no AIO Receiver operation. In this 
instance, the X register will be set to -1 to inform 
the user that the AIO Receiver will not be effective. 
A "check" operation is still required on the file be- 
fore another I/O operation may be performed. 

3. If a "check, no wait" is performed on a device that is 
busy with some file other than that specified by the 
check call, the check operation will be performed 
with an implied wait but only until the device is free 
for use by the specified file. For example, a busy 
status returned on a "check, no wait" operation always 
applies to the file specified by the Check call and if. 
an AIO Receiver was specified, it will be honored. 

4. If the AIO Receiver merely retriggers the task that 
initiated the operation, a danger exists in that it is 
quite possible for the AIO Receiver to operate before 
the task exits from its "active"state. Thus, the cur- 
rently active task is retriggered, which results essen- 
tially in a no-operation. One means of avoiding this 
problem would be to have the AIO Receiver set a flag 
to inform the active task that it has run. In this way, 
the active task could inhibit interrupts prior to exiting, 
test whether the AIO Receiver has already operated, 
and is so, restore interrupt status and return to the 
start of the task. If examination reveals that the AIO 
Receiver has not run, the task merely exits through 
M:EXIT which will properly restore the interrupt status. 
Another means of avoiding this difficulty is to have 
the AIO Receiver trigger a task lower in priority than 
the active task. This lower priority task could re- 
trigger the task initiating the I/O operation, thereby 
providing a positve trigger. 

The form of the call to the AIO Receiver by the I/O Inter- 
rupt task is 



LDA 



RCPYI 



AIODSB 



P,L 



(device status byte 
from AIO in bits 0-7, 
device number in 
bits 8-12) 



AIO Receiver Address 



The AIO Receiver routine must return to the location 
contained in the L register on entry. All registers are 
assumed to be volatile, which means that they need not 
be saved and restored to their former contents. Because 
the AIO Receiver is processed at the priority level of 
the I/O Interrupt, the processing in this routine should 
be of very short duration so as not to interfere with other 
I/O operations that may be in process. See also "End 
Action" in Chapter 5. 



CHECKPOINTING THE BACKGROUND 

A foreground program may require use of the background 
area for either instructions or data. A checkpoint feature 
is included in RBM to allow access to the background area 
by a foreground program by writing any active background 
program onto the RAD and extending memory protection to 
the background area. 



A checkpoint operation is initiated by a call to MrCKREST 
with the appropriate option. MrCKREST will return a status 
specifying whether or not the request was honored. The 
request will not be honored if the background has already 
been either checkpointed by a foreground request or auto- 
matically checkpointed as a result of loading a nonresident 
foreground program extending into the background. It is 
the responsibility of the user to schedule the use of the 
background space by foreground programs. The actual 
checkpointing is accomplished either at the priority level 
of the RBM Control Task or at the priority of the calling 
task. 



If the checkpoint is performed at the priority level of the 
calling task, a return from MrCKREST with a status of zero 
(A = 0) indicates that'the checkpoint has been performed. 
If the checkpoint is to be performed at the level of the RBM 
Control Task, the requesting program must exit its "active" 
state to allow the checkpoint operation to be performed. 
The program requesting the checkpoint would generally 
specify a "Checkpoint Complete Receiver". This receiver 
is operated at the priority level of the RBM Control Task 
when the checkpoint is complete. 



The receiver will generally retrigger the requesting pro- 
gram to inform it of the completion of the checkpoint. 
Return from the Checkpoint Complete Receiver is to the 
location contained in the L registers on entry. All registers 
are assumed to be volatile, and need not be saved and 
restored to their former contents. 



When the foreground program no longer requires use of the 
background area, it should restart the background task by 
a call to MrCKREST with the "restart" option. 
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7. OVERLAY LOADER 



The Overlay Loader can be used to create overlay programs 
for later execution in either the foreground or background. 
Overlaid programs can be permanently entered (as a file) 
into either the system or user processor areas, or into a 
temporary overlay file. Since they are stored on the RAD 
as an absolute core image, they can be quickly loaded into 
memory for execution. 

A general overlay structure is illustrated in Figure 7. The 
structure is restricted to a permanently resident root seg- 
ment and any number of overlay segments. (For background 
and nonresident foreground programs, the permanent root 
segment is resident only during actual execution.) For fore- 
ground programs, the TCB and the initialization routine 
(if one is present) must be in the root segment, but data 
and instructions can be located in both the root and the 
overlay segments. 

A COMMON data area can also be established for use by 
the root and overlay segments. 

Each segment is created by the Overlay Loader from one or 
more object modules (assembly language, FORTRAN, or 
library routines). The control commands required to create 
the overlay segments are defined in this chapter. During 
execution, the Monitor service routine MrSEGLD is used to 
control both the loading and the transfer of control between 
various segments. 

The overlay segments must be explicitly defined at load 
time and explicitly called at execution time. There is no 
provision for automatically calling in a new overlay seg- 
ment by a subroutine reference. However, the subroutines 
on a particular path may communicate with each other, with 
the restriction that it is the program's explicit responsi- 
bility to ensure that any subroutine referenced is cur- 
rently in core. 

The Overlay Loader accepts input in Standard Sigma 2/3 
Object Language from predefined, prepositioned files, and 
prepares output in absolute core-image form on the RAD to 
be read by the RBM Loader (MrLOAD) for later execution 
in either foreground or background areas. If a resident or 
nonresident program can tolerate c loading delay of 20 to 
100 ms, foreground or background programs of virtually un- 
limited size can be constructed by the use of overlays de- 
spite limitations in available core storage. 

In creating core images on the RAD, the Overlay Loader 
performs the following functions according to user options: 

• Satisfies external reference/definition linkages and 
resolves forward reference and displacement chains. 

• Searches specified libraries for unresolved references 
and loads these selected routines into core memory. 

• Builds the OVrLOAD table for the loading of overlay 
segments. 



• Writes the overlay cluster onto the OV file. 

• Allocates COMMON. 

• Allocates temporary storage stacks. 

• Creates a Task Control Block (TCB) and initialization 
information. 

• Creates the Public Library and associated transfer 
vectors (TVECT). 

• Outputs maps of segment names and addresses, external 
definitions, and information concerning COMMON 
and temporary areas. 

• Allocate, initialize, and satisfy reference linkage for 
Labeled COMMON. 



OVERLAY CLUSTER ORGANIZATION 

The overlay cluster is the collection of absolute overlays 
formed by the Overlay Loader from relocatable binary ob- 
ject modules. (Note that the Loader does not accept an 
absolute load origin in any input module.) An overlay 
cluster usually consists of two principal sections; the root 
segment and the overlay segments although it may consist 
of only a root segment. Each segment consists of one or 
more binary modules and associated library routines. Over- 
lay segments are numbered in any order by the user, except 
for the root segment, which is always designated as seg- 
ment 0. Those segments in core memory at any one time 
form a path. An overlay cluster with several paths is shown 
in Figure 8. Segments are shown as horizontal lines and, 
in this example, are numbered in the order in which they 
are built by the Overlay Loader. Note that at a given node, 
each path associated with a branch must be completed before 
a new branch is connected to this node. 

The overlay cluster shown in Figure 8 consists of a root and 
segments 1 through 15. Segments 0, 1,3, 4, 5, 6 constitute 
a path. On the RAD or disk pack the root is preceded by 
a file header, one RAD granule in length, that contains in- 
formation by which the RBM Loader MrLOAD can correctly 
read the root. The root is resident at all times during exe- 
cution of the overlay program and contains information 
(OVrLOAD table) for loading of the remaining overlay 
segments. 

When first defined along a path by an object module, 
Labeled COMMON will be allocated preceding that mod- 
ule. Should the same Labeled COMMON be subsequently 
defined by another module, the area prescribed should be 
no greater than that already allocated, and reference to the 
initial definition wii! be provided. Allocated space for 
Labeled COMMON is cleared to zero entries except where 
data is provided by modules of the same segment (or root). 
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Figure 8. Sample Overlay Cluster Configuration 



CORE LAYOUT DURING LOADING 

Background memory during the operation of the Overlay 
Loader is divided into four areas: 

1. A fixed area large enough to contain the background 
temp stack, the Overlay Loader root, and the Loader 
overlays. 

2. The segment table, fixed at 10(n+l) where n equals 
the number of segments which contains the user's 
OVrLOAD table. 

3. A dynamic area in which the segment is loaded. 

4. A dynamic area containing the symbol tables (alloca- 
tion is eight words per symbol). 

If areas 3 and 4 overlap at any point in the load process, 
overflow occurs and loading aborts. 



Library modules of the root may not initialize Labeled 
COMMON allocated in the program portion of the root. 
The number of Labeled COMMON blocks associated with 
a module is limited to 40. 

Communication between segments by external reference/ 
definition linkages is subject to the following restrictions: 

1. No segment in a path may reference a segment in 
another path. 

2. The user must ensure that all communicating segments 
are in core memory during execution. 

3. Because the Overlay Loader will satisfy a linkage only 
within a path, identical references and defintions 
may be used in different paths that do not contain a 
common segment. However, the user must avoid refer- 
ences to the same definition in defferent higher level 
segments. 

4. Library search procedures for a User or System Library 
restrict the use of unique library DEFs and REFs to a 
maximum of 225 along any path of the program. 

5. Forward references in library modules of the root are 
disallowed, and it is suggested as good programming 
practice that User Library programs not make references 
outside the library routine. 

To satisfy any remaining unsatisfied primary references, 
the Overlay Loader searches the following libraries in the 
specified sequence: 

1. Public Library 

2. Monitor Service Routines 

3. Basic or Extended Library 

4. Main Library 



OVERLAY LOADER OPERATIONAL LABELS 

The Overlay Loader references the operational labels listed 
below. Some assignments are user-defined, while others 
are handled internally by the Job Control Processor or by 
the Overlay Loader itself. All other operational labels 
referred toon !$LD cards must be assigned and positioned 
by the user prior to the IOLOAD card. 

Label Explanation 

CC Control commands. 

DO Control commands as read from CC, maps, and 

diagnostic messages. The default assignment is 
that given by the Job Control Processor on read- 
ing a !JOB card. 

GO Sequential-access file that contains object mod- 

ules to be processed by the Overlay Loader. 
Object modules are written onto GO by a pre- 
ceding processor. The Loader rewinds GO 
initially. GO receives a default assignment by 
the Job Control Processor to the permanent file 
RBMGO in the System Data area. 

LI Assigned internally to System or User Library as 

library searches are performed. 

OC Abort messages and Overlay Loader messages 

that require operator attention. 

OV Output file for the Overlay Loader containing 

the completed overlay cluster. If the user wishes 
to have the overlay cluster in a permanent file, 
he must key in SY (for write -protected files) and 
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OV is assigned to the permanent file RBMOV in 
the System Data area. 
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Labi 



Explanation 



Label 



Explanation 



PI Used for loading the Overlay Loader's own 

overlays. PI is assigned by the Job Control 
Processor. 



ID Processor to RBMID (a one-sector file) in the 

(cont. ) System Data area. 



XI Temporary RAD or disk pack scratch file con- 

taining the symbol table for each segment. XI 
is assigned by the Job Control Processor. 

X2 Assigned internally to System and User Library 

as library searches are performed. 

RS Assigned internally to read the RBM Symbol 

Table (RBMSYS) from the System Data area. 

LS Assigned internally to read the Public Library 

Symbol Table (LIBSYM) from the System Data 



ID An optional operational label used to write 

the indents of nonlibrary programs for use by 
Debug at execution time. If the user assigns 
ID, the assignment must be for a blocked file 
that has a record length of five words. By 
default, ID is assigned by the Job Control 



MAP 

Three types of maps may be output to the DO device 
following PASS2, according to one of three Map con- 
trol commands that may be input: a Short map (!$MS), 
Long map (!$ML), or Program map (!$MP). If no map 
control command is specified, no map will be output. 



Figure 9 shows the format for a Long Map. Note that 
DEFs in the Permanent Symbol Table are mapped after 
the Overlay Task line. The format for a Program map 
would be the same as the Long map except that library 
and Permanent Symbol able symbols are suppressed. The 
lines of the map that are flagged with an asterisk (*) show 
the format and output of a Short map (in an actual Short 
map no asterisk would appear in the listing). A definition 
of each item of the map is included in Figure 9. 



-MAP 




fFOl 

-OVERLAY TASK i \ ORG = xxxx HLLOC = xxxx CBASE = xxxx CSIZE = xxxx UMEM = 

IbaJ 


xxxx SECT = xxxx 


fNONEl 
*ROOT ORG = xxxx LWA = xxxx LEN = xxxx TRA = \ \ SEV = xxxx OVrLOAD 

IxxxxJ 


= xxxx 


[f ] DEF S S S S.S S S S L/I S/U/P B/E/M yyyy 
1 12J45678 




[f f JREF S.S S S S S S S LI S/U B/E/M zzzz 
12 12345678 




-SEGMENT IDENT NODE ORG LWA LEN TRA SEV 




xxxx xxxx xxxx xxxx xxxx xxxx xxxx 




[f ] DEF etc. 




[f f JREF etc. 




REF 




-SEGMENT 




^SEGMENT 




*ERRSEV = xxxx 




-END MAP 





Figure 9. Long (Load) Map Format 
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where header keywords hav 


e the following meaning: 


Overlay Task Keyworc 


s 


ORG 


First word address of the Overlay Task area. It is the FWA of the Temp stack. 


HLLOC 


Last word address of longest segment. 


CBASE 


Base of COMMON. 


CSIZE 


Largest COMMON size encountered. 


UMEM 


The number of locations between the end of the longest path, and either the beginning 
of COMMON or the end of the assigned task area. 


SECT 


The number of sectors required to store entire overlay duster. 


Root Keywords 




ORG 


FWA address of the root. In the foreground, this is assumed to be the address 
of the TCB; in the background, it is the FWA of the root. 


LWA 


Last word address of the root segment. The area from ORG to LWA includes 
the root code and the OVrLOAD table (and in the foreground, the TCB). 


LEN 


LWA-ORG+1. 


TRA 


Background — last end transfer encountered on a module used to form the root. If there 
is no transfer address, 'NONE' is output. 




Foreground —the entry address of an initialization routine that arms and optionally 
triggers interrupts at run time. If the Loader builds the TCB, it is assumed that no 
such initialization exists and TRA=NONE. 


SEV 


Error severity encountered during loading binary modules. Taken from the END item of 
the binary module. 


OVrLOAD 


Address of the OVrLOAD table. 


General Keywords 




f l f 2 


Error and identifier flags preceding external definitions and references. Possible flags 


are: 




D Double definition or reference. 




LC Labeled COMMON 




U (DEF) — a definition declared, but given no value. 




U (REF) — reference unsatisfied in this path. 




P Primary reference. 




S Secondary reference. 


DEF 


An external definition. 


REF 


An external primary or secondary reference. 


S . . . S 


EBCDIC DEF/REF name of one to eight characters. 



Figure 9. Long (Load) Map Format (cont.) 
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General Key wo 


rds (cc 


nt. ) 


L/I 




Library or Input REF/DEF. 


s/u/p 




System, User, or Public Library. 


B/E/M 




Basic, Extended, or Main mode. 


yyyy 




Value of a DEF. 


zzzz 




The number of the segment in which this reference was satisifed. For unsatisfied 
references, zzzz is blank. 


Segment Keywords 




IDENT 




Numerical identifier of this segment as found as the first parameter on the !$SEG card. 


NODE 




The numerical identifier of the segment to which this one will be attached. If NODE 
is the root, is output. 


ORG 




Beginning location (execution) of this segment. The point in core at which loading 
begins. The first reserves before data in a segment are not output. 


LWA 




LWA of this segment. Includes areas defined by RES and ORG. 


LEN 




LWA-ORG+1. 


TRA 




The last encountered transfer address is placed as an entry point in the OVrLOAD table 
for this segment. 


SEV 




Same as for ROOT. 


ERRSEV 




Total error severity for loading process (0 or 1). If any SEV > or there are unsatisfied 
primary references, ERRSEV=1. Only in forming a PUBLIB do double DEFs or unsatisfied 
secondary references cause ERRSEV=1. 


END MAP 




Completion of loading process. 



Figure 9. Long (Load) Map Format (cont. ) 



CALLING OVERLAY LOADER 

The Overlay Loader is requested via an IOLOAD com- 
mand which causes the root segment of the Loader to 
be read into core memory from the RAD. The form of 
the command is 



IOLOAD [segments, O ,S,D,X,cmn][,R] 



whe 



segments denotes the number of segments in the 
overlay cluster. If "segments" is not specified, 
a zero is used, denoting that only a root segment 
is to be loaded. The value of the segments param- 
eter may exceed the actual number of segments to 
be loaded. 



F or B specifies either a foreground (F) task or a 

background (B) task. The default case is 
background. 

S specifies a step mode of loading to be used for 

paper tape input. 

D indicates the indent of each nonlibrary module 

is to be written to operational label ID for use by 
Debug at execution time. 

X indicates that the Loader is to abort the job if 
a severity error greater than zero is encountered 
during loading. The loading procedure is com- 
pleted and the map is output. 

cmn for background tasks, cmn denotes an optional 

COMMON size; for foreground tasks, cmn denotes 
either a base for COMMON or, in the case of 
zero COMMON, the upper limit of the task 
area. If the address specified by the cmn param- 
eter is higher than root FWA. Foreground loads 
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may specify the cmn parameter at a lower address 
than root FWA, in which case the end of memory 
is the program upper limit. A check is made at 
the end of the load to determine whether the 
COMMON allotment overlaps the root. If it 
does, the warning message OLERR CO is printed 
but no error severity level is set. 

R for foreground tasks only, specifying that this 

parameter causes only the root size to be entered 
into a sector header (OVrLOAD table) instead of 
the program's longest path. The root size is not 
reflected in any map. 

This action is intended for the use of a foreground 
program that only occasionally uses a large data 
buffer. A program of this nature can reside in 

until such time as it requires background space. 
Caution must be exercised in the use of this pa- 
rameter, since the background must be explicitly 
checkpointed and restored, when necessary, by 
the foreground task. 

When the step mode of loading is defined, the operator is 
notified after the loading of each module from paper tape 
by the message 



!! BEGIN WAIT 



Depressing the console interrupt button and keying in an S 
will initiate either the loading of the next module from the 
paper tape unit or the reading of the next control com- 
mand. An X response causes the loading process to abort. 

In allocating COMMON for background programs, the 
Overlay Loader compares the cmn parameter with the first 
nonzero COMMON size allocation value encountered in 
loading and employs the larger of these two values. The 
COMMON base is set by subtracting the COMMON size 
from KrUNAVBG. 

For all foreground programs having COMMON, the follow- 
ing rules apply: 

1. Default 

a. COMMON upper limit is the upper limit of non- 
resident foreground (K:BACKP-1). 

b. COMMON base Is K.-BACKP-l minus COMMON 
size. 

2. cmn specified 

a. cmn will be used as COMMON base or FWA of 
COMMON. 

b. COMMON size will be added to cmn to determine 
the COMMON upper limit. 

3. Blocking buffers will always be allocated immediately 
preceding COMMON base. 

4. If COMMON base is "reater than TOTam FWA it 
will be used as an upper limit for program loading. If 
not, K:BACKP-1 will be used and the 'R' option may 
not be used. 



Reading an !EOD control command causes the Overlay 
Loader to satisfy forward references, output any specified 
map, close files, and return control to RBM via MrTERM. 
The form of the command is 

!EOD 



CONTROL COMMAND FORMAT 

Except for the IOLOAD command, which is read by the Job 
Control Processor, the Overlay Loader control commands 
are read from the CC device under Loader control . The 
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!$mnemonic parameter 



/here 



! identifies the record as a control command. 

$ indicates that the control command is unique to 

the Overlay Loader. 

mnemonic is the code name of an Overlay Loader 

control command and begins immediately following 
the !$ characters. 

parameter is a series of optional or required param- 

eters unique to the specific command. The formats 
of parameters are (1) a decimal integer of up to 
five positive numbers but having a value less than 
32,767; (2) a hexadecimal string of the form 
±xxxx; (3) an EBCDIC string of up to eight char- 
acters but not exclusively characters through 9; 
or (4) a string of the form EBCDIC string ± hexa- 
decimal number. 

From one through eight blanks are permitted between the 
mnemonic and the first parameter. If more than eight blanks 
blanks are detected, the parameter list is considered empty. 

The only allowed delimiter between parameter fields is a 
comma; no embedded blanks are allowed in or between any 
fields. A single blank terminates the parameter string. 
Two successive commas indicate an empty field. Comments 
are allowed on a control card. 



CONTROL COMMAND REPERTOIRE 

BLOCK The !$BLOCK control command will allocate 

blocking buffers from unused memory space as requested 
either by a count or by defining operational labels that may 
require blocking buffers at run time. The list of such labels 
along with limits of available memory will be passed via the 
file header to M:LOAD, which will allocate a blocking 
buffer poo! at run time. The ooo! will be utilized dynam- 
ically to provide blocking buffers in cases where a call to 
RBM routines MrREAD or M:WRITE is not preceded by a call 
to MrOPEN. A call to MrCLOSE may release any such 
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buffers. Thus, if two operational labels were to use a block- 
ing buffer area at different times, the first might release the 
area for use by the second. Only one of the two labels 
would be required on the !$BLOCK command. 

M:LOAD checks which of the operational labels are assigned 
to block files at run time to make the pool allocation. If 
such an allocation overflows the available memory space 
(between the end of the longest path and COMMON), the 
execution aborts. However, the user may define his own 
blocking buffer by specific calls toM:OPEN. Such an area 
should be in a reserved area of his own path. He should not 
use the dynamically allocated pool area, and blocking buf- 
fers may not be allocated in temporary stacks. Only one 
! $BLOCK command is allowed in a single fob step, except 
when used with multiple !$TCB commands. The format of 
the !$BLOCK command is 



! SBLOCK {° P ' b l} [,oplb 2 , . . . ,oplb n ] 



where oplbj defines an operational label (which is a two- 
letter mnemonic or a FORTRAN device unit number; e.g., 
BI, SI, F:106). The oplb; parameter may not be a device- 
file number or file name. The oplb must be assigned to a 
block file. Only 10 operation labels will be read; addi- 
tional ones will be ignored. In lieu of operation labels, 
the user may provide a count (c) of blocking buffers required. 

LIB The !$LIB control command specifies a new default 
library loading mode for the entire loading process. If the 
LIB command is not present, the Overlay Loader follows 
the default case (Basic System Library). !$LIB cards may 
occur at any point in the control deck and will take effect 
from that point. The format of the command is 

!$LIB library,x[,y] 



where 



library must beoneof the following EBCDIC codes. 

Code Library 



Basic 
Extended 



x /[y] specify the order of search. The x and y pa- 
rameters are either of the fol lowing EBCDIC codes. 



Code 

S 

U 



Library 
System 
User 



The order in which they are specified determines the 
order of search. Note that if y is not specified, only 
x will be searched. 

MS, ML, MP The Map control commands specify that 

map information is to be output on DO. The three forms 
of map commands are shown below. 



If the ! $MS (Short Map) control command is specified, only 
root and segment headers will be output. Also output is a 
summary containing the origin of the overlay program, the 
length of the longest path, temp stack size, memory that is 
available for the blocking buffer pool, and the COMMON 
base. The format of the command is 

/iSMS 



If the ! $ML (Long Map) control command is specified, the 
short map plus external references and all external defini- 
tions and their values including the libraries and permanent 
symbol table are output. Double definitions, and definition 
declarations that were not given a value are flagged D 
and U, respectively. Unsatisfied primary references are 
flagged with UP, unsatisfied secondary references with US. 
The format of the command is 

!$ML 



The output of the !$MP control command is identical to 
that of !$ML, except that library definitions and references 
and the permanent symbol table are suppressed. The format 
of the command is 

/!$MP 



If relevant, information concerning the Public Library is 
also mapped. 

TCB The ! $TCB control command indicates (for a fore- 

ground task only) that the Overlay Loader must create a 
TCB and reserve a PSD location, and must generate a call 
to RBM routine MrSAVE. MrFSAVE will be called if the 
set multiple precision mode exists. In addition, information 
to initialize the TCB at run time will be passed in the file 
header. If no !$TCB command is present, it is assumed that 
a TCB has been assembled into the root segment. Since the 
background TCB lies in protected memory, it cannot be as- 
sembled into the root of the background overlay cluster, but 
the necessary information is passed by the Loader to M:LOAD 
via the file header. Therefore, the TCB option applies to 
foreground tasks only. Multiple !$TCB commands maybe 
used internal to the root program. Each !$TCB command 
would connect a separate interrupt function to the root pro- 
gram and be followed by ! $LD commands to load associated 
modules. The ! $TCB may be followed by a !$BLOCK com- 
mand that would identify independent buffer blocks with its 
function. Individual temp stacks will be reserved by other 
than the initial ! $TCB command that must precede the 
!$ROOT command. The format of the command is 



! $TCB w.,w 9 [,temp] 



wo are the values to be placed in words 1 and 2 
of the created TCB (see "Real-Time Programming, 
Chapter 6). 
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temp defines the size of the temporary stack to be 
reserved for a TCB other than the initial TCB. 

The Overlay Loader will handle specific and default 
cases of program execution and TCB initialization within 
the framework of the following restrictions: 

• The Overlay Loader defines all background Task Con- 
trol Blocks completely, using the value of the temp 
parameter on the !$ROOT card, load information, and 
the !$BLOCK parameters. 

• In foreground tasks, if the user assembles the TCB as 
part of the program, it either must contain all informa- 
tion as data or as external references satisfiable at 
load time, or be initialized by the task itself. A trans- 
fer address is assumed to be a transfer to an initializa- 
tion section that will do any required housekeeping, 
arming, enabling, or triggering the task. If no trans- 
fer address exists, MrLOAD will arm and enable and, 
optionally, trigger the task using information in 
words 1 and 2 of the TCB. 

• If the Overlay Loader initializes the TCB by means of 
the TCB parameters, it does so completely, using load 
information and values on the ! $TCB and !$BLOCK 
cards. No partial initialization of a TCB is allowed 
with the exception of the blocking buffer pool. If a 
user builds his own TCB, the TCB must begin at the 
execution location plus the "temp" value specified 
on the !$ROOT command. 

• For foreground tasks for which the Loader builds a TCB, 
the Loader will create the PSD reserve and a call to 
MrSAVE. The user's root is then entered either at the 
location specified in the transfer address, or at the 
FWA of the root when the transfer address is missing. 
The map will indicate a transfer address of "NONE" 
for the root. 

• Where multiple !$TCB commands are used within the 
root program, the transfer address for the program is 
established by the modules preceding a second use of the 
!$TCB. FORTRAN generated programs do not provide 
a transfer address. If no transfer address exists, each 
subtask within the root program will be initialized by 
MrLOAD using the information in words 1 and 2 of 
their respective TCB. If a transfer address is provided, 
MrLOAD will not initialize any subtask. 

The user exits with either a call to the RBM routine MrEXIT 
or by a standard exit procedure. 

Public Library routines and Monitor service routines called 
by the user program will require temporary storage areas 
that are dynamically allocated at execution time. These 
temporary storage areas must be allocated in a fixed storage 
stack that is reserved by the Loader at ioad time on the 
basis of the temp parameter on the ! $ROOT control com- 
mand. In addition, the Loader will insert in the TCB the 
first and last word addresses of the area. The temp area 
will be allocated preceding the root segment. It need not 
be a reserve in the module. 



For more information on initialization and structure of TCBs, 
see Chapter 6. 

ROOT The !$ROOT command specifies that the modules 

that follow it constitute the root segment of the overlay 
cluster. A ! $ROOT command must precede all !$SEG com- 
mands, and may be followed by !$LD, !$INCLUDE, 
!$EXCLUDE, !$TCB, !$LCOM, !$RES, !$MD, !$LIB, and 
! $LB commands, which cause the loading of those modules 
that form the root segment. Loading of the root will begin 
at the first cell following the temp stack for the background 
task. An execution bias may be specified. The user must 
ensure that the root segment, exclusive of any library load- 
ing, is less than 32K bytes. The root and its library are 
written as two records. Therefore, the library portion of 
the root may aios be a maximum of 32K-I bytes, which 
cives a maximum root s>ze n f a r > nr< ">*' m <itplv 39K words. The 
format of the command is 

!$ROOT [temp,exloc,oplb, n] 



temp defines the size of the overlay cluster's tem- 
porary stack needed for the largest possible nesting 
of Public Library and Monitor service routines. 
The default size is 80 cells. If a TCB has been 
assembled into a foreground program, this value 
should be used for temp. 

exloc specifies the beginning location of the area 
in memory that the overlay cluster will occupy at 
execution time. The default case is KrBACKBG 
for a background task and KrNFFWA for a fore- 
ground task. The temp stack will be allocated at 
exloc. 

oplb,n specifies that n modules are to be loaded 

contiguously from the operational label oplb. No 
default is provided. 

Note that if the oplb parameter is absent, ! $LD (Load) or 
!$INCLUDE control commands must follow !$ROOT to 
specify loading. If oplb is present and the n param- 
eter is empty, loading proceeds from oplb until an !EOD 
is encountered. 



LD The ! $LD control command identifies one or more 

modules to be loaded as part of a segment. Each input file 
must be ordered in the same sequence as the ! $LD cards in 
the control stack accessing that file. The Overlay Loader 
reads only relocatable binary modules from the GO file and 
other input files specified on !$LD, !$SEG, and !$ROOT 
cards. All files must be pre-positioned (GO is rewound by 
the Loader), and the modules must be in the same position 
on each file as calls on that file. The use of the IDNT on 

*.L_ ifln I j.U_ I I! „r j.U_ _~J l„ 

trie :j?\-\-*> cuiu CH3UIC3 me luuuiny ui iu€ piGper mOGUle. 

Note that the file must be positioned to the proper module 
in the file when the Loader reads from that file. Since 
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there are no file-positioning control commands recognized 
by the Overlay Loader, each file must be constructed in 
correct sequential order. The form of the command is 



A 



$LD [oplb] 



Jidentl 
'Inm J 



where 



oplb is the operational label of the medium from 

which the binary module is to be loaded. The 
default case for an empty field is GO. 



fidentl 
Inm J 



ident is on EBCDIC representation of the 
ID NT of the program to be loaded. It is 
used for checking purposes only. If nm is speci- 
fied, it indicates the number of modules to be 
loaded from oplb; no check of any ident is made. 
If this parameter is an ident, one module is 
loaded. If empty, loading proceeds until an EOD 
is encountered. 

LB The ! $LB command controls the search of libraries 
(for this segment only) to satisfy external references en- 
countered during the loading of modules forming the seg- 
ment. If the !$LB control command is omitted, the 
Overlay Loader will first attempt to satisfy all references 
by definitions in other segments of that path or from the 
root, and then will search the libraries specified by ! $LIB 
or by the default case. Individual ! $LB cards supersede 
! $LIB or default for that segment only. Libraries are 
searched only on occurrence of a !$SEG or !EOD control 
command. !$LIB and !$LB cards only set the mode and 
sequence of search. Only libraries on the RAD or disk pack 
may be loaded selectively using the ! $LB command. To 
input "library" programs from other media, the user must 
use standard ! $LD commands. The format of the com- 
mand is 



A 



!$LB library,m[,n] 



/here 



library 



must be one of the following EBCDIC codes: 
Code Library 



Basic 
Extended 



[, n] specify the order of search. The m and n 

parameters are either of the following codes: 

Code Library 



System 
User 



If n is not specified, only m will be searched. There are no 
default cases for E, B, m, and n. 



INCLUDE The !$INCLUDE control command specifies 

external definitions in those library modules that are to be 
loaded with this segment, even though they are not refer- 
enced in the segment. Their definitions will be included 
in the Symbol Table for use by higher-level segments. 
More than one I$INCLUDE command may be used. Li- 
braries are searched according to a preceding !$LB or ! $LIB 
card or the initial default case. The format of the com- 
mand is 

! SINCLUDE def [,def , . . . ,def ] 



where def- is an external definition of a library program to 
be included in the segment. 

EXCLUDE The !$EXCLUDE control command inhibits 

library search and linkage for the named definition(s) even 
though an external reference occurs in a module of the seg- 
ment. The format of the command is 



A 



SEXCLUDE def r def 2 , 



,def 



where defj is the external definition for a library routine 
that is not defined along the current path. If def- is one 
of several definitions associated with a specific library pro- 
gram, then excluding the one def is sufficient to forestall 
loading of its associated library module. 

MD The !$MD (modify) control command is used to 

change core locations at load time before the absolute 
overlays are written out onto the OV file. ! $MD commands 
must be inserted within a SEG sequence and apply only to 
the segment being loaded. A check is made that the 
effective address of the ! $MD command lies in the segment 
and that any labels used are defined for the path the seg- 
ment lies in. The Overlay Loader aborts if the modifica- 
tion location lies outside the limits of the segment. In- 
serted values are not tested for range. External symbols 
(definitions) used in loc or value must have been previ- 
ously defined. The format of the command is 

!$MD loc, value rvalue., value_, ..., value 1 
L I I n J 



/here 



loc specifies the execution location of the first 

modification. 

value? is the hexadecimal quantity to be inserted 

at loc + i (for example, value is inserted at loc, 
value, at loc + 1, etc.). 



Both the loc and the value; parameters are subject to the 
restrictions set forth in "Control Command Format". Note 
that it is not possible to modify a library module by use of 
an ! $MD control command. 
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RES The ! $RES control command allows the user to 

reserve an area at the end of the segment (root) program for 
run-time patching. The format of the command is 

!$RES def,size [,def,size], . . . [,def,size] 



where 

def is the name of the area to be reserved. 

size is a decimal value specifying the number of 

words in the reserve area. 

LOOM The !$LCOM control command allows the user 

to allocate labeled COMMON blocks within a segment 
(root) program. The format of the command is 

! $LCOM block,size [,block,sizeJ . . . [,block,size] 



block is the one-to-eight character EBCDIC name 

of the labeled COMMON block. 

size is a decimal value specifying the words to be 

allocated for the block. 

SEG l The !$SEG control command defines the modules 
that will form a segment. Numbers used to define a seg- 
ment must be unique. Segment identifier numbers need not 
be consecutive. A segment, including its library, is re- 
stricted to a maximum of 16, 112 bytes since the segment 
and its library are written as one record on the RAD. 

Each ! $SEG or ! $ROOT control command may be followed 
by !$LD, !$MD, !$INCLUDE, !$LIB, and ! $LB commands 
to load the modules to form that segment. The loading for 
a segment terminates on a new !$SEG control command. 
The control command stack is terminated by an !EOD. The 
user may defer the loading of a specific library routine 
through the application of the !$EXCLUDE command. The 
Loader will attempt to satisfy all references present at a 
level from the libraries specified on !$LB, !$LIB, and 
!$INCLUDE commandsor from the default library case. A 
given library is searched only once per segment. The format 
of the command is 

!$SEG si,sn[,oplb,n] 



^here 



si is a number less than or equal to X'FF 1 used to 

identify the segment being loaded. It will be 
used to call the segment at run time. 

sn is the number of the segment to which this seg- 

ment is attached. 

oplb,n specifies that n modules are to be loaded 

contiguously from the operational label oplb. 



The following rules should be observed in defining segments 
for the overlay cluster: 

1. The longest segment must fit into core with the Loader 
and its tables. If a segment is too long, it may be re- 
assembled as two modules and loaded as two segments. 

2. The Loader will first attempt to satisfy library refer- 
ences using the Public Library and then will search the 
appropriate iibraries on the RAD or disk pack. Using 
the !$INCLUDE command, other often-used library 
routines can be loaded with the root where they will 
be accessible to all segments. However, library rou- 
tines loaded in any segment will be accessible only to 
segments in the same path. 

3. Where segment content (not the root) is preceded by 
reserve area, such area does not consume space during 
the loading process. However, if a Labeled COMMON 
block is initially defined by the first module of a seg- 
ment, it is considered a data area that will precede all 
reserve areas which will consequently consume space 
during Loader processing. 

At execution time an explicit call to RBM routine MrSEGLD 
with the segment identifier number and the ADRL OVrLOAD 
causes the reading of that segment into memory from the 
OV file. Thus, any segment may, by an explicit call, 
cause any other segment to be loaded for execution. 

PUBLIB The !$PUBLIB control command indicates that 

the Overlay Loader is to create a Public Library using mod- 
ules that follow and/or modules from selected libraries. 
The Public Library is biased at the location specified in 
KrPLFWA of the RBM. Each symbol is flagged as Extended, 
Basic, or Main according to control information on the 
! SPUBLIB card. However, a library may contain routines 
of more than one mode. Such identical definitions of 
different modes are differentiated in the Symbol Table 
(LIBSYM) and are not considered duplicate. 

When library routines are part of the Public Library, they 
must be reentrant and therefore must use the dynamic tem- 
porary stack (specified as the temp field on the ! $ROOT 
command) for their temporary storage space. To conserve 
core space when forming the Public Library, the Loader 
will remove any trailing RES from a library routine and will 
also change the appropriate word in the calling sequence 
for M:RES, MrPUSH, or MrPUSHK so that the dynamic 
temporary stack will be used for temporary storage space. 

A severity level of 1 is set if unsatisfied references or 
double definitions are encountered during the loading of a 
Public Library, and the library will not be written onto the 
PUBLIB file. When a Public Library is being created, the 
Overlay Loader creates a new Public Library on the RAD 
or disk pack. The Public Library just loaded is written 
onto the PUBLIB file in the User Processor area. The total 
length of the Public Library must not exceed 9191 words. 
The Monitor Services Transfer Vector (TVECT) file is read 



C C..-».^. 

1 i win jyji cm 



D «„«. ~-«^ 



I U^CMUI 



,J iUr> D. 



/ 



is updated and written onto TVECT. A new Public Library 
Symbol Table is written to LIBSYM file in the" System Data 
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area. The new LIBSYM is incompatible with the Public 
Library currently in core. All files are closed and nor- 
mal termination through M:TERM takes place. The new 
Public Library is then loaded into core by rebooting the 
RBM. The format of the command is 

!$PUBLIB library-mode[,oplb,n] 



where 

mode must be one of the following EBCDIC codes: 

Code Mode 



B 


Basic 


E 


Extended 


M 


Main 



A new !$PUBLIB control command must be pro- 
vided each time mode is to be changed. 

oplb,n specifies that n modules are to be loaded 

contiguously from the operational label oplb. 

!$LD, !$LB, !$INCLUDE, and !$MD commands are hon- 
ored when using !$PUBLIB in the same manner as for the 
!$SEG command. !$ROOT, !$TCB, and !$SEG commands 
may not be used in conjunction with the !$PUBLIB command. 

END The !$END command is treated exactly like an 

!EOD command. It should be used in place of !EOD when- 
ever multistep job stacks are to be prestored on a RAD file. 
The Utility COPY routine will not interpret this com- 
mand as end-of-file (EOF). The format of the command is 

!$END 



LOADER ERROR MESSAGES 

The Overlay Loader program outputs messages on both OC 
and DO concurrently with the load operation. If OC and 
DO are assigned to the same device, duplication of mes- 
sages on DO is suppressed. If an operator response is re- 
quired, the message 



!! BEGIN WAIT 



is written on OC and DO. The operator activates the con- 
sole interrupt and keys in either of the following codes. 

Code Meaning 



Continue. 



Abort Overaly Loader and return control 
to RBM. 



The format of the error message where an operator response 
is required is 



OLERR xx 



where xx is a two-letter mnemonic that identifies the error. 
The types of Overlay Loader messages are as follows: 

1. Warning messages, after which loading continues. 

2. Response messages, requiring an S or X key-in from 
the operator. 

3. Abort messages, upon which the Overlay Loader exits 
via the RBM routine MrABORT (see Appendix C for 
abort codes, abort messages, and their meanings). 

The Overlay Loader error messages are given in Table 18 
below. 



Table 18. Loader Error Messages 



Message 


Meaning 


LIBSYM UNDEFINED* 

OLERR BU 

OLERR CC ! BEGIN WAIT 


There was no file entry on the system Data area of the RAD or disk pack for 
the LIBSYM table. 

Sufficient blocking buffer space unavailable. Severity level is set. 

A control command card has a format or parameter error. An S response 
causes the next control command to be read in from CC This may be a 
corrected command to replace the one in error. 


This message may be written on DO during writing of the Public Library, LIBSYM or TVECT table onto the RAD or 
disk pack. If the alarm occurs, the Public Library was not completely written and will have to be reloaded after the 
error is corrected. 

The Loader does not reposition the record for rereading. If paper tape or cards are repositioned, the record is re- 
read; if they are not repositioned, the next record is read. If the record is on RAD, disk pack, or magnetic tape, the 
Monitor I/O error recovery procedures positions to the beginning of the next record. However, the WAIT permits the 
taking of dumps, etc. , before changing the environment. 
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Table 18. Loader Error Messages (cont. ) 



Message 


Meaning 


OLERRCS UBEGIN WAIT 


There was a checksum error on a binary record. An S response causes the 
record to be reread." 


OLERR CO 


Foreground COMMON, based below root, overlaps root. Warning only, no 
severity level set. 


OLERR IB !! BEGIN WAIT 


Illegal binary format (that is, the first word was not 'FF 1 or '9F') was de- 
tected. An S response causes the record to be reread. ^ 


OLERR ID ! JBEGIN WAIT 


The indent on the binary module just loaded does not compare with the indent 
specified on the ! $LD command. On an S response, the Loader accepts the 
binary module as is and continues processing. 


OLERR IS !! BEGIN WAIT 


Control commands were improperly sequenced in the control command stack 
An S response causes the next control command to be read. However, if the 
sequence error was due to a SEG command, the Loader aborts. ^ 


OLERR RC 


Trailing reserve overlapped COMMON; no error severity level is set. 


OLERR SQ UBEGIN WAIT 


There was an incorrect sequence number on a binary record. An S response 
causes the record to be reread." 


OLERR TA 


No transfer address was encountered in the loading of the root program por- 
tion. This is only a warning message. The Loader sets a default transfer 
address as the first word of the program and generates an error severity level 
of one. 


OLERR UR f 


There were unsatisfied references in the path. This is only a warning message. 


TOO MANY DEFS t 


There were more DEFs in the Public Library than were allocated at system 
generation. 


OLERR US 


A symbol table entry was not recognized (warning only). 


This message may be written on DO 
disk pack. If the alarm occurs, the 
error is corrected. 


during writing of the Public Library, LIBSYM, or TVECT table onto the RAD or 
Public Library was not completely written and will have to be reloaded after the 


The Loader does not reposition the 
if they are not repositioned, the nex 
tor I/O error recovery procedures po 
of dumps, etc. , before changing the 


record for rereading. If paper tape or cards are repositioned, the record is reread; 
t record is read. If the record is on RAD, disk pack, or magnetic tape, the Moni- 
sitions to the beginning of the next record. However, the WAIT permits the taking 
environment. 
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8. RAD EDITOR 



The RAD Editor controls RAD and disk pack allocation by 
maintaining file directories for all resident standard areas. 
A resident standard area is one that has its area mnemonic 
in the RBM Master Directory (either as a permanent area 
defined at SYSGEN or a temporary area defined by the 
Mount key-in) and is not checkpoint (CP), background 
temporary (BT) area, or of any area whose mnemonic begins 
with the character X. (X identifies a nonstandard area. ) 
Through its control commands the RAD Editor can 

Add entries to or delete entries from file directories 

Copy data from one random file to another 

Maintain libraries in the system library (SL) and user 
library (UL) areas for use by the Overlay Loader 

Copy an object module contained in a library 

Map file and library module allocations 

Dump contents of areas or random files 

Save the contents of areas or files in a format restor- 
able by the RAD Editor, or save the contents of areas 
in a rebootable format on magnetic tape (which may 
also be restored by the RAD Editor) 

Clear an area or file 

Truncate a file or all files within an area 

Output messages to the operator 

Initialize file directories for new disk packs 

Flaw bad disk pack tracks and allocate alternates. 

The RAD Editor generates and maintains directories for the 
following permanent areas: 

System Processor area (SP) 

System Library area (SL) 

System Data area (SD) 

User Processor area (UP) 

User Library area (UL) 

User Data area (UD and aa ) 



Size and location of each permanent area are contained 
in the RBM Master Director. The RAD Editor allows map- 
ping of all areas, including Checkpoint and Background 
Temp areas, and the dumping of all random-access files. 



STANDARD RAD/DISK PACK AREA ORGANIZATION 

Every area contains its own file directory. Each file is 
identified by a file directory entry that indicates the name, 
format, and location of the file. The areas and their file 
directories are software write- protected (at SYSGEN) and 
may have any of the following four write-protect codes: 

Code Meaning 

NO only files with a write-protect code of NO 

may be added to the area. 

BG only files with write-protect codes of NO 

or BG may be added to the area. Back- 
ground programs may write on any file in 
the area, but foreground programs may only 
write on files with NO write-protect codes. 

FG only files with write-protect codes of NO 

or FG may be added to the area. Fore- 
ground programs may write on any file in 
the area, but background programs may only 
write on files with NO write-protect codes. 

SY files with any write-protect codes may be 

added to the area. 

For areas with BG or NO write-protect codes, any RAD 
Editor control command may be used without the need for 
an SY key-in. However, for areas with FG or SY write- 
protect codes, the following RAD Edit control commands 
require that an SY key-in be in effect at the time the con- 
trol command is executed: 

!#ADD 

! # DELETE 

! # TRUNCATE 

! # SQUEEZE 

{^RESTORE 

! # CLEAR 

Space within an area is allocated sequentially; the first file 
in the area begins in the first sector following the first file 
directory. The second file in the area begins in the next 
available sector following the first file. Normally, as each 
file is added to the area, the next available sector is used 
as the start of the new file; however, the control command 
used to allocate space for the file may specify that the file 
begin on the next available track (or cylinder) boundary. 
In this event, any space bypassed will remain unused and 
the RAD Editor will not attempt to fit a new file into the un- 
used space. New files are always added at the end of the 
currently allocated space within an area. 
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When a directory entry (and, effectively, its corresponding 
file) is deleted, the area formerly occupied by the file is 
left unused. In normal operation, the RAD Editor makes no 
attempt to recover these unused areas. Therefore, the 
addition of a file may cause overflow of the permanent area 
although ample space may be available. However, RAD 
squeezing can be requested via an Editor ! ^SQUEEZE com- 
mand to overcome this problem. Squeezing recovers the 
unused storage within a permanent area by regenerating the 
directory and moving files. 

Before any permanent file can be written (using the Moni- 
tor routine MrWRITE), space must be allocated for the 
file. This is accomplished by requesting the RAD Editor 
to add a new entry ot the designated directory. Con- 
trol commands aiiow directory entries to be added or 

UCICICU. 



DATA FILES 

Ordinarily, data is not written in permanent files by the 
RAD Editor. Data files are normally written by user pro- 
grams. However, a RAD Editor control command can be 
used to copy data from one random-access file to another. 
Copied files may be temporary or permanent files. 



LIBRARY FILES 

System and User Library files, which are searched by the 
Overlay Loader for external references, are generated and 
maintained by the RAD Editor (the only processor that 
writes in these files). 

A library area (either the System Library area or the User 
Library area) contains six files: 

1. Module Directory File (directory of library modules). 

2. EBCDIC File (list of all library definitions/references). 

3. Extended DEF/REF File (index to extended precision 
definitions/references in EBCDIC file). 

4. Basic DEF/REF File (index to standard precision 
definitions/references in EBCDIC file). 

5. Main DEF/REF File (index to main definitions/ 
references in EBCDIC file). 

6. Module File (library object modules). 



The extended and basic DEF/REF files (items 3 and 4) are 
optional. 

These files are generated and maintained from information 
in control commands and object modules placed in the 



library by the RAD Editor. Special commands are supplied 
to allow the addition and deletion of object modules; these 
control commands will cause the six files in the RAD Li- 
brary area to be updated. A control command allows an 
object module contained in a library to be copied onto BO. 

Any random-access or sequential-access file (either tem- 
porary or permanent) can be dumped on LO. 

The RAD Editor can save the contents of a permanent area 
and the RBM bootstrap in a self-reloadable form. The 
saved image contains a bootstrap loader, the execution of 
which restores the RBM bootstrap and the permanent area 
on the RAD or disk pack. 

Updating or squeezing of permanent areas and library files 
that contain information for real-time TOrtrorns must not 
occur while the foreground is using these permanent areas 
or files. The user must ensure that the RAD Editor is not 
modifying a permanent area while a foreground program is 
using it. 

The names for the library files must be one of the following: 

Code File 



MODIR 


Module Directory 


EBCDIC 


EBCDIC 


EDFRF 


Extended DEF/REF (optional) 


BDFRF 


Basic DEF/REF (optional) 


MDFRF 


Main DEF/REF 


MODULE 


Module 



The DEF/kEF file needs to be added only as required. The 
System Library (SL) requires only the MDFRF file. 



ALGORITHMS FOR COMPUTING LIBRARY FILE SIZES 

The following algorithms may be used to determine the 
lengths of the six files in a library area: 

The number of granules in the MODIR file is 



MODIR 



6 (1 + i) 



is the number of modules to be placed in the 
library (including main, extended-precision, and 
single-precision routines), i must be equal-to or J 
less-than 1023. 

is the granule size in words. 
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The number of granules in the EBCDIC file is 



The number of granules in the MDFRF file is 



EBCDIC 



4 (1 + d) 



MDRFR 



2+J> + r +d) 

_iz! L_L 



d is the number of unique DEFs and REFs in the 

library (including main, extended-precision, and 
single-precision routines), d must be equal-to 
or less-than 8191. 

g is the granule size in words. 

The number of granules in the EDFRF file is 



EDFRF 



2+ S (2 + S + V 



n is the number of routines in the main library. 

r. is the number of REFs in the jth library routine 

in the main library. 

d. is the number of DEFs in the jth library routine 

in the main library. 

g is the granule size in words. 



The number of granules in the MODULE file is 



n is the number of routines in the extended- 

precision library. 



n 



MODULE n = £ f ( C .) 
i - 1 



rj2 is the number of REFs in the extended-precision 

library. 

dj2 is the number of DEFs in the extended-precision 

library. 



n is the number of modules in the library (includ- 

ing main, extended-precision, and single- 
precision routines), and n must be equal -to or 
less-than 1023. 



g is the granule size in words. 



The number of granules in the BDFRF file is 



g is the granule size in words. 



c. is the number of record images in the ith library 

1 

routine. 



2 +E(2 + r, + d, ) 



BDFRF = — 

n 9 



k "W 



is the number of routines in the single-precision 
library. 



r, is the number of REFs in the kth library routine 

in the single-precision library. 



d, is the number of DEFs in the kth library routine 

of the single-precision library. 



RAD EDITOR OPERATIONAL LABELS 

The RAD Editor uses the temporary background operational 
labels X0 through X6. These labels must not be assigned at 
the time the 1RADEDIT control command is executed, nor 
may they be used on PDUMP or I^FCOPY commands. 

The following labels must be assigned before requesting the 
RAD Editor: 

Label Explanation 



BI 



BO 



Object module input (and Restore) to System 
and User Library. 

Object module output (and Save) from the 
System and User Libraries. 



g is the granule size in words. 



CC Control command input. 
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Label Explanation 

DO Log of control commands error messages, 

and operator key-ins. 

LO Maps of directories and dumps of files. 

OC Messages to the operator and key-ins from 

the operator. 



CALLING RAD EDITOR 

The RAD Editor is requested with a IRADEDIT control com- 
mand. The IRADEDIT control command is read from CC 
and causes the root segment of the RAD Editor program to 
be loaded into core memory from the RAD. It has the format 



IRADEDIT 



Reading an !EOD from CC causes the RAD Editor program 
to return control to the Monitor. If CC is assigned to 
magnetic tape or a RAD file, an EOF condition encoun- 
tered while reading control commands from CC will cause 
the RAD Editor to return control to the Monitor. The form 
of the command is 

!EOD 



CONTROL COMMAND FORMAT 

All RAD Editor control commands are input from CC and 
listed on DO. If CC and DO are assigned to the same de- 
vice, the commands are not listed. The general format is 

!*menmonic specification 



where 



! identifies the record as a control command. 

* indicates that the control command is unique to 

the RAD Editor. 

mnemonic is the code name of a RAD Editor com- 

mand immediately following the !* characters. 

specification is a series of required or optional 

parameters unique to the specific command. The 
conventions used in specifying parameters are 
(1) a string of up to five decimal digits, having 
a value less than 65,535, denotes a decimal in- 
teger; (2) a string of the form +xxxx is treated as 
hexadecimal; (3) all other strings are assumed to 
be nonnumeric. 



One or more blanks must separate the mnemonic and speci- 
fication fields, but no blanks may be embeddded within a 
field. An empty parameter in the specification field is 
denoted by a comma. However, commas may be omitted 
for empty trailing parameters. A control command is 
terminated by the first blank after the specification field. 
If the specification field is absent and a comment follows 
the mnemonic field, the command is terminated by a period. 

The first two characters of the mnemonic portion of the 
command are sufficient to define the command; the re- 
maining characters may be omitted since they are ignored 
if they are present. 

In the descriptions of the following individual commands, 
certain terms are used that have specific meanings for the 
RAD Editor. The terms are: 



Term 



ffN 



identification 



library 



Meaning 

The two-character alphanumeric 
mnemonic fora resident standard area. 
The area mnemonic must be currently 
present in the RBM Master Dictionary 
and, generally, may not be BT, CP, 
or Xn. 

For the commands !*LADD, 
! # LREPLACE, ! # LDELETE, ! # LCOPY, 
! # LMAP, and ! # LSQUEEZE, area must 
be either SLorUL. If neither is speci- 
fied, SL is assumed by default. 

Three to eight alphanumeric characters 
denoting a file contained within (or 
to be added to) an area file directory. 

The library routine name denoted by 
the Extended Symbol ID NT directive, 
which is located in the start module 
load item of an object module. 

An object module library (within the 
System or User Library) denoted by one 
of the codes 

Code Library 



M 
E 



Main 

Extended 

Basic 



For the commands !"lADD, 
! # LREPLACE, and ! # LDELETE the de- 
fault library is M (main). 



CONTROL COMMAND REPERTOIRE 

ADD The !*ADD command adds a new entry to the 

specified permanent file directory. It defines the name, 
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size, record length, format, and write protection for the 
new file. It may also declare that the file will contain 
a resident foreground program, and will be maintained start- 
ing at a cylinder or track boundary- Space is allocated for 
the new file and the first sector of the file is set to zero 
if it has random format. The form of the command is 



! # ADD area filename,] . . } ,| . f 
LfsizeJ LrsizeJ 



[,filefmt] 



3 



-[,wp] 



jnra 



ALL indicates the file will be allocated to extend 

to the end of the area. After an EOF has been 
written on the file, it may be truncated to recover 
the unused space. 

fsize is the number of records in the file and may 

not exceed 65,535. 

rsize is the maximum number of bytes per record 

which must be even and may not exceed 65,534. 
The following default values are provided, depend- 
ing on the file format. 

Default Record Size 

• 120 for file format, B and P 

• Sector size, in bytes, of the device contain- 
ing the area for file format R or U 

• 80 for file format C. Since compressed files 
may contain records of variable length, this 
value is used for allocation purposes only. 
The S character may be used to force the 
allocation of a specific number of sectors for 

a compressed file. In this case, fsize indicates 
the number of sectors to reserve for the com- 
pressed file. 

filefmt is the structure of the file, as denoted by 

one of the following codes: 

Code Format 

B blocked sequential -access file with a 

fixed record size 

C blocked (and compressed) sequential access 

file with a variable record size 

P blocked (packed) random access file, 

fixed record size 

R unblocked random access file 

U unblocked sequential access file. 



wp 



If the format parameter is omitted, the default for- 
mat is determined by the area mnemonic as follows: 

Default Area Mnemonic 

R SP,SL,UP,UL,FP,BP 

B any other 

specifies the write-protection level for the file, 
as denoted by one of the following codes: 

Codes 



Write-Protection Level 

NO (or N) No write-protection; background 

or foreground programs may write 
on the file. 

BG (or B) Write permitted by background 

programs only. 

FG (or F) Write permitted by foreground 

programs only. 

Background programs may write on 
the fi le if an SY key-in is in effect. 

SY (or R) Write permitted by RBM only. 

Foreground or background programs 
may write on the file if an SY 
key-in is in effect. 

If the wp parameter is omitted, the default write- 
protection level is NO. 

RF or F specifies that the file will contain a resi- 

dent foreground program, and therefore the area 
mnemonic must be SP, FP, or UP. 

CYL specifies that the BOT of the file is to be 

allocated and maintained on a cylinder boundary 
if the area is on a disk pack. 

TRK specifies that the BOT of the file is to be 

allocated and maintained on a track boundary. 

DELETE The !*DELETE command deletes on entry from 
the specified permanent file directory. The space formerly 
allocated to the file becomes unused. The space is recov- 
ered if the file being deleted is the last file in the area. 
The Form of the command is 



/l#DELETEarea[f filename ] 
I (.area J 



If no filename is specified, all files in the area are deleted. 
If the area is SP, SL, or SD a filename must be specified; 
otherwise, the operation is not performed. Instead, the 
following message is output 



NO CHANGE: area 



If the write-protect code for the area is SY or FG, the SY 
key-in must be in effect at the time the control command 
is executed. 
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FCOPV The ! # FCOPY (File Copy) command copies data 

from one random-access file to another. The file copy pro- 
cess terminates when EOF is encountered on an input file or 
when an end-of-tape is encountered on either the input or 
the output file. The form of the command is 



! # FCOPY oplb 1 ,oplb 2 



Within a permanent area (SL or UL), each object 
module must have a unique "identification". If 
the identification parameter is omitted, all object 
modules on BI will be added to the library up to, 
but not including, the file mark or EOD on BI. 

If identification is present, the start module load 
item of the first program read from BI must be the 
same as shown by the identification parameter. 



/here 



oplbj is the operational label or FORTRAN device 

unit number (e.g., F: 109) of a temporary or 
random-access file. The Utility COPY Routine 
(see Chapter 9) must be used to copy sequential- 
access files. 

oplb] is the input file. 

oplb2 is the output file. 

DPCOPY The ! # DPCOPY (Disk Pack Copy) control 

command copies data from one disk pack (model 7242 or 
7246) to another. The entire contents of cylinders through 
199 are copied and a checkwrite is performed on the copied 
data. The form. of the command is 

/ ! # DPCOPY device 1 ,+device 2 



where 

device] is the hexadecimal device number of the 

disk pack 

device2 is the hexadecimal device number of the 

disk pack to copy to, which may not contain any 
currently "mounted" areas. 

LADD The ! # LADD (Library Add) command adds an 

object module to the designated library. The object 
module is read from BI, checked for sequence and checksum 
errors, and stored in the Module File within the library. 
From the data in the object module and on the control com- 
mand, the information about the module is extracted and 
placed in the Module Directory File (MODIR), the EBCDIC 
File, and one of the three DEF/REF Files (either MDFRF, 
BDFRF, or EDFRF File) as indicated in the library param- 
eter. BI may be assigned to any device; if BI is assigned 
to the RAD, it must be sequential file. The object mod- 
ule on BI must be in Standard Sigma 2/3 Object Language. 
Any blank card or binary card on BI that contains only zeros 
is ignored. The form of the command is 



! # LADD [area,][ident][,library] 



wh« 



LREPLACE The ! # LREPLACE (Library Replace) command 
replaces an object module of the same identification in the 
designated library. The object module is read from BI and 
checked for sequence checksum errors. The object moduie 
on BI must uc in Standard jigrna 2/3 Object Language. 
Any blank card or binary card (on BI) that contains only 
zeros is ignored. The form of the command is 



! # LREPLACE [area,]ident[,library] 



/here 



identification is the program name located in the 

start module item of the object module on BI. 
The object module on BI replaces the module in 
the library having the same identification. 

LDELETE The !#LDELETE (Library Delete) command 
deletes an object module from the designated library. The 
form of the command is 



! # LDELETE [area,] ident [,libraryj 



/here 



identification is the program name of the object 

module to be deleted. 

LCOPY The ! # LCOPY (Library Copy) command copies 

an object module from the designated library onto the BO 
device. The form of the command is 



! # LCOPY [area,] ident 



identification is the program name located in the 

start module item of the object module on BI. 



identification is the program name (located in the 

start module item) of the object module to be 
copied onto the BO device. 

LSQUEEZE The !#LSQUEEZE (Library Squeeze) com- 

mand will squeeze designated library areas. Unused space 
is recovered by regenerating the directory files and 
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squeezing (compacting) the module file. The form of the 
command is 



| /! # LSQUEEZE[area] 



MAP The PMAP command causes the specified direc- 

tories to be mapped on LO. For each permanent RAD area, 
the beginning and ending RAD addresses for the area are 
mapped. For each file, the contents of the directory entry 
describing the file are printed. This information includes 
name, format, write-protection, foreground task indicator, 
beginning address, EOF address, and EOT address for each 
file. For files on disk packs, the map also includes the 
cylinder/track/sector values for BOT. For files on RADs, 
the map also includes the track/sector values for BOT. The 
form of the command is 



! # MAP[a 



rea,] [,area,_] . . . [,area 1 



/here 



area must be a currently defined area. If no area 

parameter is included, all currently defined areas 
are mapped. 

LMAP The l^LMAP command causes the library files of 

the specified areas to be mapped on LO. For each area, 
the beginning and ending addresses for the area are mapped, 
followed by a map of the library files in the area. The 
library map includes the following information for each 
routine: 



Library B (basic), E (extended) or M (main) 

Identification of routine 

Length of routine in words 

Sector within the MODULE file that contains the routine 

DEFs in the routine 

REFs in the routine. 

The form of the command is 



! # LMAP [area [,area]] 



DUMP The PDUMP command dumps a random-access 

I file on LO. The file is dumped one record at a time. 
The DUMP Utility Routine (see Chapter 9) may also be used 
to dump sequential -access files. DUMP represents each 
word as a four-character hexadecimal number. It dumps 
I each record of the file starting at BOT (if starting address 



is not specified) and ending at EOT or after the speci- 
fied number of records has been dumped. The form of the 
command is 



/! # DUMP {°|^}[,start[,number]] 



oplb is the operational label or FORTRAN device 

unit number (e.g., F: 109) assigned to a random 
access file. 



start is the record number within the file assigned 

to oplb at which the dump is to begin. If an area 
is specified, start is the sector number (in the de- 
vice containing the area) at which the dump is to 
begin. If start is omitted, the BOT of the file (or 
area) is used by default. 



number is the number of records (or sectors if an 

area is specified) to be dumped. If number is 
omitted, the file (or area) is dumped to its 
EOT. 



SAVE The S^SAVE command saves the contents of areas 

of specific files. Each file is written on the BO device, 
along with all pertinent information about the file. The BO 
media may be magnetic tape, paper tape, or cards. If the 
media is magnetic tape and an end-of-reel condition occurs, 
the operator is expected to mount the next reel to be used 
for output. If the media is paper tape and an ! ATTEND 
command has been input for the current job, the message 



nnnn FT. OK? 



will be output on the OC device. If there is more than nnnn 
feet of paper tape available, the operator is expected to 
type in Y. This process will continue until all files speci- 
fied by the !*SAVE command have been output, or until 
the operator determines that the required amount of tape is 
not available. Any input other than Y causes the pro- 
gram to output an end-of-reel record followed by blank 
trailer. The program then outputs the message 



!! BEGIN WAIT 



on the OC device. The operator must then mount a new reel 
of tape, interrupt, and key-in S. The program then out- 
puts blank leader, a save-continuation record, and proceeds 
as described above. 
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The BO output can be restored via the ! ^RESTORE command. 
The form of the command is 



^SAVELFILEjareafi^ 60 },...! 
J | IfilenameJ 



•] 



where 
FILE 



indicates that the output format contains a!! 
necessary information for the restoration of specific 
files. The FILE keyword may be omitted only if the 
BO operational label is assigned to magnetic tape, 
causing a bootstrap program to be output on BO 
followed by the contents of the specified areas. 
No filenames may be specified in this case, since 
the allocated portion of an area is saved as if it 
were a single file. 

When self-booted from magnetic tape, the boot- 
strap program will restore the saved areas and then 
initiate an RBM boot process. 



RESTORE The ! ^RESTORE command restores the contents 
of areas of specific files that have been saved via the 
!*SAVE command. The files are selectively restored from 
the BI device. The form of the command is 



!#RESTORE[areaf",K ea },..,], 
MfilenameJ 



•] 



If the file being restored does not have a corresponding 
entry in the area file directory, a new entry is made and 
the file is copied into its allocated region. If the file being 
restored already has an entry in the area file directory the 
file will be copied into the currently allocated region unless 

• There is a format conflict 

• The allocated region is too small 

• The proper level of write authorization is not in effect that 
is, SY key-in not performed and file is write-protected. 

If an end-of-reel condition is encountered while reading 
from BI the operator will be requested to mount the next reel 
in sequence, as created by the !*SAVE command. 

If the BI input is a rebootable save tape, no filenames may 
be specified — each area is restored in its entirety. 

SQUEEZE The ! # SQUEEZE command compacts the 

designated file areas. Unused space is regained by regen- 
erating the directories and moving files. The form of the 
command is 

l # SQUEEZE area[,area]. . . [,area] 



The areas BT, CP, and any area beginning with the letter X 
are never squeezed. An explicit request to squeeze any 



of these is ignored. If the area being squeezed contains a 
file that is assigned to an operational label and the file is 
moved, the following message will be output using the OC 
and DO operational labels. 



REASSIGN: area, filename 



File directory information may be destroyed if an area being 
squeezed contains a file that is assigned to an operational 
label being used by an active foreground program. 

CLEAR The !*CLEAR command zeros out the specified 

RAD area or file. The form of the command is 



I 



# CLEAR area 



r« 



Y\ filename] 



)]■ 



If no filename is specified, all files in the area are cleared, 
including file directories. If the area is SP and no filename 
is specified, the operation will not be performed. Instead, 
the following message will be output 



NO CHANGE: SP 



If the write-protect code for the area is SY or FG, the SY 
key-in must be in effect at the time the control command is 
executed. 



BDTRACK The ! # BDTRACK command specifies the disk 

pack and the track numbers for which alternates are to be 
provided. The original track will have its headers rewritten 
with a flaw mark and a reference to the alternate track. 
The headers of the alternate track will be rewritten to refer 
to the original track. The form of the command is 

!*BDTRACK +dn,+number[,+n'jmber]. . . [,+number] 



where 

dn is the device number of the disk pack. 

number is the hexadecimal track number on the de- 

vice starting with 0. 



Example: 

/l#BDTRACK+E5, +325, +297 



GDTRACK The ! # GDTRACK command specifies the disk 

pack and the track numbers for which alternates are to be 
eliminated. This may be used if it is suspected that a 
designated flawed track is good. For each track specified, 
its headers will be rewritten to clear the flaw mark and the 
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headers of the assigned alternate track will be rewritten to 
free the alternate track. The form of the command is 

! # GDTRACK -+dn,+number[,+number]. . . [,+number] 



where 

dn is the device number of the disk pack. 

number is the hexadecimal track number on the 

device starting with 0. 

INITIALIZE The ! # INITIALIZE command provides disk 

pack serialization (including date) and allocation of data 
areas. The form of the command is 



! INITIALIZE +dn [serial -number] 



wp is the write-protect code to be used for the area. 

This code is tested whenever any of the following 
operations are performed: 

ADD RESTORE 

CLEAR SQUEEZE 

DELETE TRUNCATE 

See "Standard RAD/Disk Pack Area Organization" for write- 
protect codes. 

MESSAGE The ! # MESSAGE control command writes 

messages to the operator on the OC and LO devices. The 
form of the command is 

! # MESSAGE message 



where message is any EBCDIC character string up to a full 
card image. 



dn is the hardware device number of the RAD or 

disk pack to be initialized. The device number 
must match a RAD or disk pack device number 
input at SYSGEN. 

serial number is any combination of eight charac- 

ters, which need be present only if the device is 
a disk pack. If present, serial-number is written 
on cylinder 202, track 19, sector together with 
the current date. If the RBM system does not in- 
clude [ob accounting, the operator will be re- 
quested to input the current date when it is 
required. 

The {^INITIALIZE command may be followed by a set 
of area definition cards that have the format 



/ !^area=tracks[Avp] 



area is an area mnemonic from the following 

list: 



SP 


FP 


Xn 


SD 


BP 


SK (skip tracks) 


SL 


UP 




BT 


UL 





CP aa 



tracks aa is the number of tracks to be allocated 
for the area. 



PAUSE The I^PAUSE control command causes a message 

to be written on the OC and LO devices followed by a wait 
for the operator's response. The form of the command is 

! # PAUSE message 



where message is any EBCDIC character string up to a full 
card image. The format of the output is: 

! # PAUSE message 
HBEGIN WAIT 

It is necessary for the operator to activate the control panel 
INTERRUPT switch and key-in an S to continue. 

TRUNCATE The l # TRUNCATE command elimiates un- 

used space from the end of specific files by setting the 
EOT pointer equal to the EOF pointer. If an EOF has not 
been written on the file, the file EOT will not be changed. 
All compressed files or files containing programs loaded by 
the Overlay Loader (or with the Monitor !ABS command) 
will have an EOF pointer. The form of the command is 



! # TRUNCATEarea 



{area 
filename 



)]■ 



If no filename is specified all files in the area containing 
an EOF are to be truncated to the EOF. If the area is SD 
and no filename is specified, the following message will be 
output on the OC and DO operational labels. 



NO CHANGE: SD 



If the write protect code for the area is SY or FG, the SY 
key-in must be in effect at the time the control command 
is executed. 
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END The !*END command is used exactly like the !EOD 

command; that is, it transfers control from the RAD Editor 
to the Monitor. The form of the command is 

l # END 



This command should be used in place of !EOD whenever 
multistep job stacks are to be prestored on a file. The 
Utility COPY routine will not interpret this command as 
an EOF. 



RAD EDITOR MESSAGES 

The RAD Editor program outputs error messages on OC and 
DO. If OC and DO are assigned to the same device, 
duplication of messages on DO is suppressed. The warning 
messages in Table 20 are written on the OC and DO 
devices to provide a record of operations not performed or 



of critical operations in process. If an operator response 
is required, the message 



! BEGIN WAIT 



is written on OC and DO. The operator activates the con- 
sole interrupt and keys in either of the following codes. 



Code 

S 
X 



Meaning 

Continue. 

Abort RAD Editor and return control to RBM. 



To abort, the RAD Editor calls the Background Abort rou- 
tine, MrABORT. If the RAD Editor aborts because of an 
irrecoverable input/output error, the code in the abort 
message is the operation label of the device in error. If 
the abort is due to an X response by the operator or some 
error condition, the code is RE. 

The error messages output by the RAD Editor and their mean- 
ings are given in Table 19. The messages in Table 20 are 
written on the keyboard/printer during RAD restoration via 
the bootstrap loader produced by SAVE. Any error output 
causes the computer to go into a wait state after writing the 
appropriate message. 



Table 19. RAD Editor Error Messages 



Message 


Meaning 


OVERFLOW: area, 
filename 


Allocation of the amount of storage indicated by the file parameter on the ! *ADD command 
or restoration of a file not currently allocated would cause the permanent area to overflow, 
or a library file has overflowed during execution of a !*ADD command. RAD Editor reads 
the next command from CC. 


ASSIGN ERR: area, 
filename 


The RAD Editor was unable to assign an operational label to a filename because the number 
of available RAD or disk pack device-file numbers is insufficient or because the specified 
file does not exist. RAD Editor aborts. 


CKSM ERR 


The last record in the object module being read from BI has a checksum error. If the job 
is ATTENDed, operator response is solicited; an operator response of S causes the Editor 
to read the next record from BI. RAD Editor aborts. 


CHCK WRITE ERR 


A check write error occurred (that is, data recorded on the RAD or disk pack could not 
be verified). 


CORE OVERFLOW 


The last command cannot be processed for lack of background space. The RAD Editor 
aborts. 


DUP IDENT 


The last object module read from BI cannot be added to the library with a PLADD com- 
mand because it is already in the library. RAD Editor aborts. 


DUPLICATE: area, 
filename 


An attempt was made to add a file whose name already exists for this area. The RAD Editor 
reads the next command from CC. 


EDIT ERR 


Data on the RAD or disk pack has been rendered invalid. RAD Editor aborts. 
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Table 19. RAD Editor Error Messages (cont. ) 



Message 


Meaning 


EMPTY oplb 


The device assigned to the operational label is in manual mode. 


EOFoplb 


An unexpected end-of-file was encountered on the device having the operational label 
oplb. RAD Editor aborts. 


EOF READ FILE 


An EOF has been encountered on the input file. Copying will continue until EOT on the 
Read file or EOT on the Write file is encountered. 


EOT oplb 


An unexpected end-of-tape was encountered on the device having the operational label 
oplb. RAD Editor aborts. 


EOT WRITE FILE 


An unexpected EOT occurred on the file currently receiving data. This is a warning to 
the user that the output file is smaller than the input file (as in I^FCOPY) but that the 
data already written is correct. The RAD Editor reads the next command from CC. 


CALL SEQ ERR oplb 


A calling sequence error occurred for input/output on the device having the operational 
label oplb. RAD Editor aborts. 


FORMAT CONFICT: 
area, filename 


The filename being restored to the area conflicts in format or record size with the existing 
filename in the area. 


OVERFLOW: area, 
filename 


If it is not possible to add a file during the execution of the !*ADD command or a file in 
the library area has overflowed during execution of the PLADD command. If operator 
response is S, the next command is read. 


ILLEG BIN 


An illegal binary record (first byte not X'FF 1 or X'9F') has been read with an object 
module on BI. RAD Editor aborts. 


INV CTRL 


Control command is invalid. It cannot be recognized by RAD Editor or has incorrect 
syntax. If operator response is S, the next command is read. 


INV I/O OP oplb 


An invalid input/output operation was attempted on the device having the operational label 
oplb. RAD Editor aborts. 


LENGTH ERR oplb 


A record of incorrect length was read from or written on the device having the operational 
label oplb. RAD Editor aborts. 


LOAD ERR 


The required RAD Editor overlay cannot be loaded. RAD Editor aborts. 


NO ALTERNATE 


An alternate track is not available for execution of the !*BDTRACK command. The RAD 
Editor reads the next command from CC 


NO BLOCK oplb 


No blocking buffer is available for the file assigned to the operational label oplb. RAD 
Editor aborts. 


BAD IDENT 


The object module on BI does not have the same "identification" in the start module item. 
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Table 19. RAD Editor Error Messages (cont. ) 



Message 


Meaning 


NO IDENT 


The identification in start module item is blank, or there is no object module on BI. RAD 
Editor aborts. 


CAN'T FIND area, 
filename 


An attempt was made to save, clear, truncate, or delete a file whose name does not exist 
in the specified area, or the specified area does not exist. The RAD Editor reads the next 
command from CC. 


PARAM ERR 


Control command has a parameter error. A parameter has incorrect content, has been 
omitted, or is not consistent with the other parameters. A parameter error also occurs for 
duplicate Editor commands; that is, when an already-existing file is created via the I^ADD 
command or when a nonexisting file is deleted via the ! ^DELETE command. If operator 
response is S the next command is read* 


SEQ ERR 


The last record in the object module being read from BI has a sequence error. If the job is 
attended, an operator response of S causes the Editor to read the next record from BI. If the 
job is not attended, RAD Editor aborts. 


SZ ERR 


The object module on BI cannot be placed in the library because it has more than 61 ex- 
ternal definitions and references. RAD Editor aborts. 


UNRECOVER I/O oplb 


An irrecoverable I/O error occurred on the device assigned to the operational label oplb. 
RAD Editor aborts. 


WRITE PRO oplb 


The file name assigned to the operational label oplb is SY or FG write protected and 
an SY key in is not in effect. 


{^} PROTECTED: 
area, filename 


The specified area or filename has an SY or FG write protect code and an SY keyin is not 
in effect. 



Table 20. RAD Editor Warning Messages 



Message 


ka- : 

ivicuiiniy 


CLEARING 
RESTORING 
SQUEEZING 
TRUNCATING. 


area 


These messages are output whenever the indicated operation is started. 


DONE 


Message is output when the operation is completed. 


SAVE TAPE NOT 
AT LOAD POINT 


The save tape was not at load point when the !*SAVE command was encountered and ex- 
ecution commenced. 
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9. UTILITY 



INTRODUCTION 

The Utility program operates in the background under the 
Real-Time Batch Monitor. It contains routines that: 

• Copy variable-length binary or EBCDIC records from 
one medium to another (Copy). 

• Dump records onto an output device in either hexa- 
decimal or EBCDIC format (Dump, known as Paper 
Tape Dump in the BCM system). 

• Generate or update files that contain Standard Sigma 
Object Language modules (Object Module Editor). 

• Generate or update symbolic files (paper or magnetic) 
that contain source data (Record Editor, known as 
Paper Tape Editor in the BCM system). 

• Edit card images by sequence number (Sequence Editor). 



Routines in the Utility program are device-independent. 
Utility handles anyblocked or unblocked, sequential-access 
RAD file. Use of a sequential -access RAD file is similar to 
that of a magnetic tape, as it has a beginning-of-tape, an 
end-of-file (if one has been written), and an end-of-tape. 
Note, however, that a sequential -access RAD file cannot 
be forward -spaced or backspaced over more than one file 
mark. A rewound sequential -access RAD file is positioned 
at beginning-of-tape. For both blocked and unblocked 
files, a record skip is a logical record skip. 



UTILITY PROGRAM ORGANIZATION 

The Utility program consists of two major sections: the Util- 
ity Program Control routine (always resident when the Utility 
program is operating), and the currently operating Utility 
subroutine. The Utility Program Control routine contains 
four interdependent elements: 

1. The Program Executive, which initializes the program 
(upon entry from RBM), interprets the ! UTILITY con- 
trol command (explained in "Calling Utility"), exer- 
cises control over the flow of control commands, handles 
normal and abort exits to the Monitor, and performs 

all I/O checking for the Utility program. 

2. The Source Input Interpreter, which reads and scans 
Utility control commands for the Control Function Pro- 
cessor and the current Utility subroutine. 

3. The Control Function Processor, which executes con- 
trol function commands common to all Utility subroutines. 



4. The Operator Communication routine, which outputs 
messages to OC and DO and receives key-in responses. 



UTILITY EXECUTIVE PROGRAM 

When RBM reads a ! UTILITY control command control is 
transferred to the Program Executive routine. The ! UTILITY 
control command is then scanned for parameters. If the 
name parameter is omitted (see "Calling Utility" below), 
it is assumed that only the Control Function Processor will 
be used. Utilitycontrol commands are read from the source 
input (SI) device. 

If a specific Utility subroutine is requested, the Program 
Executive verifies that the subroutine is in storage; if 
not, an error message is written and an exit to RBM is taken, 
terminating the background operation. If the subroutine is 
present, initialization of tables and flags occurs. 

The Program Executive then transfers control to the requested 
Utility subroutine. The Utility subroutine uses the Source 
Input Interpreter to read all commands, and uses the Control 
Function Processor to execute control functions. All other 
control commands are interpreted and executed by the Uti- 
lity subroutine itself. 



SOURCE INPUT INTERPRETER 

The Source Input Interpreter, which is called by the Program 
Executive routine, processes all control commands that are 
read by the Utility program. Utility control commands are 
input from the SI device and listed on the DO device as 
they are interpreted. 

Upon reading a command, the Source Input Interpreter de- 
termines whether the command is valid. If the syntax for a 
command is invalid, the following message is written on OC 
and DO: 



INV CTL 
HUKEYIN 



The operator response, either an S to continue or an X to 
abort, determines whether or not the Utility program 
continues. 

If the response is S, the Source Input Interpreter reads the 
next control command from SI. If the command is valid, it 
may be interpreted and executed either by the Utility sub- 
routine or by the Control Function Processor. 



CONTROL FUNCTION PROCESSOR 

The Control Function Processor interprets and executes com- 
mands that are common to all Utility subroutines. If any of 
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the control commands interpreted and executed by the 
Control Function Processor contains an invalid operational 
label, the following message is output: 



INV OPLB 
HUKEYIN 



The operator response, either an S to continue or an X to 
abort, determines whether or not the Utility program 
continues. 



OPERATOR COMMUNICATION ROUTINE 



All messages to the operator are written on the OC device 

r»v/ fno (jrsArrtirir rrtmmnnirnfiAn miitino 

**f ...w _(_-.- .w. _w.....,w... .„., .WW. ...V. 



If a response is required from the operator, the Operator 
Communication routine types the following message: 



! UKEYIN 



The operator then keys in either an S to continue, or an X 
to abort. 

If the response is S, a return is made to the calling routine. 
If the operator keys in an invalid response (not S or X), the 
following message is written on OC and DO. 



KEY ERR 
!! UKEYIN 



The operator then types in the correct response. 



INPUT/OUTPUT ERROR MESSAGES 

The Program Control routine performs all input/output 
checking for the Utility program. Messages regarding input/ 
output errors are written on both the OC and DO devices. 



CONTROL ROUTINE OPERATIONAL LABELS 

Four operational labels are reserved for the Program Control 
routine. Their use is restricted to the functions below; they 
may not be used in place of the labels required by the vari- 
ous Utility subroutines explained later. 

Label Explanation 

SI Device for RBM control command input, Utility 

program control commands, and various modifica- 
tion source inputs. 

DO Device for listing of control commands (as they 

are interpreted), messages, error conditions, op- 
erator responses, etc. DO provides a permanent 
log of the control command flow. This is the only 
operational label for the Program Control routine 
that can be assigned to device-file number 



Label Explanation 

DO (i.e., suppressed). If OC and DO are assigned 

(cont. ) to the same device, duplication of messages is 
suppressed. 

OC Device for messages to the operator, or key-in re- 

sponses from the operator (always via the keyboard/ 
printer). 

X5 Temporary RAD file used for prestoring commands 

read from SI. 

Utility functions are generally executed dynamically; that 
is, control commands are interpreted and executed as they 
are read. However, when several operational labels are 
assigned to the same device as SI, it is impracticai to exe- 
cute dynamically. In this case, commands must be pre- 
stored to avoid confusion with data from that device. This 
decision to prestore is made by the Utility program with one 
exception: when the ! UTILITY command has no name pa- 
rameter, the !*PRESTORE control command allows the user 
the option of prestoring SI input until an EOD card image 
is encountered. For RBM Utilities, prestored commands are 
written on a temporary RAD file (using operational label X5) 
and read from the RAD for interpretation and execution. 



CALLING UTILITY 

The Utility program is requested via a JUTILITYcontrol com- 
mand, which causes the root segment of the Utility program 
to be loaded into core memory from the RAD. The IUTILITY 
control command has the format 

IUTILITY [ name] [, parameter] 



name is the name of a Utility routine or may be 

omitted. It may be any of the following: 

COPY (Copy) 

DUMP (Dump) 

OMEDIT (Object Module Editor) 

RECEDIT (Record Editor) 

SEQEDIT (Sequence Editor) 

parameter represents the series of optional param- 

eters that are unique to each Utility routine. Pa- 
rameters are fully explained in the description of 
the individual routines. 



When RBM reads a IUTILITY command, it loads the Program 
Control routine (root segment) from the RAD and transfers 
control to the Program Executive which controls the operation 
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of the Utility program. The Executive first scans the 
! UTILITY control command parameters. If the name pa- 
rameter is omitted, the Executive assumes that the control 
commands that follow use the Control Function Processor 
only. If a specific Utility routine is referenced with the 
name parameter, the Program Executive checks the name 
for validity. If the name is invalid, the message 

UT NT RES 

(Utility not resident) is written on OC and DO and the 
Utility program aborts. If the name is valid, the overlay 
segment containing the Utility routine is loaded from the 
RAD, flags are initialized, and control is transferred to the 
named routine. 

When the Executive or Program Control routine encounters 
an !EOD card image from SI, it terminates processing. The 
form of the !EOD command is 



!EOD 



This causes the Utility program to transfer control back to 
RBM. 



CONTROL COMMAND FORMAT 

All Utility program control commands are input from SI and 
are listed on the DO device as they are interpreted. The 
general format is 

Amnemonic specification 



of the mnemonic portion of the command are sufficient to 
define a control command; the remaining characters may 
be omitted, since they are ignored when present. 

CONTROL FUNCTION COMMANDS 

The Control Function Processor interprets and executes con- 
trol commands that are common to all Utility subroutines. 
These control function commands are given below. Unless 
otherwise noted, "oplb" is the operational label of the de- 
vice, "number" is the number of file marks or records to 
skip (if omitted, the number is assumed to be I), and "de- 
vice" is the device type and physical device number. 

FBACK The !*FBACK command backspaces a magnetic 

tape over a specified number of file marks or a sequential- 
access RAD file to beginning-of-tape (BOT). The form of 
the command is 



*FBACK oplb [, number] 



The !*FBACK command cannot be used for random files. 

FSKIP The !*FSKIP command spaces a magnetic tape 

forward over a specified number of file marks or a sequential - 
access RAD file over its end-of-file. The form of the com- 
mand is 



/ \* 



FSKIP oplb[, number] 



The !*FSKIP command cannot be used for random files. 

MESSAGE The !*MESSAGE command writes messages to 

the operator on the OC and the DO devices. The form of 
the command is 



! identifies the record as a control command. 

* indicates that the control command is unique to 

the Utility program. 

mnemonic is the code name of a Utility command 

and begins immediately following the !* characters. 

specification is a series of parameters unique to 

the specific command. The conventions used in 
specifying parameters are (I) a string of up to five 
decimal digits having a value less than 32, 768 
denotes a decimal integer and (2) a string con- 
taining more than five characters Is always assumed 
to be EBCDIC, regardless of content. 

One or more blanks separate the mnemonic and specifica- 
tion fields, but no blanks may be embedded within a field. 
A control command is terminated by the first blank after the 
specification field; or, if the specification field is absent 
| and a comment follows the mnemonic field, the command is 
terminated by a period. No control command record may 
contain more than 80 characters. The first two characters 



!*MESSAGE message 



where message is any EBCDIC character string up to a full 
card image. 

The format of the output is 

!*MESSAGE message 

PAUSE The !*PAUSE command causes a message to be 
written on the OC and DO device followed by a wait for 
the operator's response. The form of the command is 

I* PA USE message 



where message is any EBCDIC character string up to a full 
card image. 

The format of the output is 

!*PAUSE message 
HUKEYIN 



Control Command Format/Control Function Commands 
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PRESTORE The !*PRESTORE command causes all control 
commands to be read from the SI device, but not to be in- 
terpreted or executed until an !EOD is read. The prestored 
commands are written on a temporary RAD file (using opera- 
tional label X5) and are read sequentially from the RAD. 
(The prestore mode is set automatically when a name param- 
eter appears on the ! UTILITY command and one or more 
operational labels have been assigned to the same device 
or RAD DFN as SI.) The !*PRESTORE control command 
must immediately follow the IUTILITY control command 
and must precede any other control commands for the Util- 
ity program. The form of the command is 

!*PRESTORE 



REWiND The !*REWIND command causes the specified 

magnetic tape or sequential-access RAD file to be rewound. 
The form of the command is 



I*REWIND oplb 



The !*REWIND command cannot be used for random files. 

RBACK The !*RBACK command backspaces a magnetic 

tape or sequential -access RAD file over a specified number 
of records. The form of the command is 



/ !*RBACK oplb[ f number] 



If oplb is assigned to a blocked sequential -access RAD file, 
the number parameter is the number of logical records to be 
skipped. The i*RBACK command cannot be used for random 
files. 

RSKIP The !*RSKIP command spaces forward the indi- 

cated magnetic tape or sequential -access RAD file over the 
specified number of records. The form of the command is 

!*RSKIP oplb[, number] 



If oplb is assigned to a blocked sequential -access RAD file, 
the number parameter is the number of logical records to 
skip. The !*RSKIP command cannot be used for random 
files. 



UNLOAD The !*UNLOAD command unloads a magnetic 

tape or closes a sequential -access RAD file. The form of 
the command is 

J*UNLOAD oDlb 



END The !*END command is treated exactly like an 

!EOD; that is, transfers control from Utility to the Moni- 
tor. This command should be used in place of !EOD when- 
ever multiactivity job stacks are to be prestored on a RAD 
file. This command will not be interpreted as an EOF when 
read from UI. The form of the command is 

!*END 



WE OF The !*WEOF command writes a file mark, EOD, 

or end-of-file pointer if appropriate to the device. The 
form of the command is 



!*WEOF oplb 



ASSIGN The !*ASSIGN command allows a Utility user 

to assign any operational label to any other background 
operational label, device-file number, or RAD file. The 
form of the command is 



!*ASSIGN 



op ib{;} 



oplb 
dfn 



LTilename 



dfn is a device-file number. 

file is a RAD file name. 

area is the RAD area within which the RAD file is 

defined. 



COPY ROUTINE 

COPY provides the ability to copy variable-length binary 
or EBCDIC records from cards, paper tape, magnetic tape, 
keyboard/printer, and sequential-access RAD files to cards, 
paper tape, magnetic tape, line printer, keyboard/printer, 
and sequential -access RAD files. Using control functions 
of the Control Function Processor, records and files can be 
skipped except for random files. Output generated by the 
COPY routine can be verified. If the binary mode is re- 
quested for either copying or verifying, file marks are re- 
cognized for paper tape, magnetic tape or sequential RAD 
file. An !EOD card is recognized as a file mark. The num- 
ber of records and files read or verified is listed upon com- 
pletion of the COPY or VERIFY operation. 

Since COPY uses RBM routines M:READ and MrWRITE for 
all reading and writing, files copied with the COPY routine 
will be treated according to the default conventions of the 
FORM, size, and BIN parameters of the !*COPY command. 
Deviation from inherent conventions is accomplished via 
FORM, size, and BIN parameter options. 
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For records being copied to the card punch, records containing 
a first byte of X'lO, X'3C, X'9F', X'BF', X'DF', X'FF', 
X'OO 1 , or X'78' are always punched in the binary mode; 
all other records are punched in EBCDIC. For all other 
devices, the distinction between binary and EBCDIC modes 
is meaningless because records are copied directly without 
translation. Therefore, attempting to copy binary data to 
an EBCDIC device will result in meaningless output. 

For paper tape, if BIN and size are not specified, the 
length of each binary record (first byte of X'lC, X'3C, 
X'9F', X'BF', X'DF, X'FF', X'OO', or X'78') is always 
120 bytes. When M:READ reads EBCDIC records from paper 
tape, it transmits only the number of bytes specified by the 
calling sequence to memory. Ordinarily, the COPY rou- 
tine assumes that paper tape EBCDIC records have a byte 
count of 120. The BIN control card allows the user to 
override the standard count. 

By assigning the X4 oplb to a RAD file or paper tape device 
before the !*OPLBS command is read, records copied from 
UI are adjusted to a 80- or 120-byte length, depending upon 
upon the contents of the first byte. 

When copying or verifying a 9-track magnetic tape to a 
7-track magnetic tape, UI and X4 should be assigned to 
the 9T magnetic tape device. 

If a record copied to the line printer or keyboard/printer 
contains more than 132 characters, only the first 132 are 
printed. Normally, the first character of the record is 
printed and single spacing is forced. Therefore, even if 
the first character is intended for format control, it will be 
printed as the first character of the print line, in the normal 
mode. If the format option is specified, the first character 
is interpreted as a format control character and is not 
printed. 

The BIN option should be used to copy nonstandard binary 
records. Paper tape codes N L, EOM, and / are not inter- 
preted as editing characters. All records are copies on a 
byte-for-byte basis. If paper tape is the input source, 
leading blanks are ignored and trailing blanks are included 
in the byte count. Paper tape !EOD NL is recognized as 
a file mark if it occupies the first five bytes of a record. 



COPY OPERATIONAL LABELS 



COPY OPERATING CHARACTERISTICS 

The COPY routine checks whether input/output operational 
labels are assigned to the same physical device. If so, all 
control commands are read from the SI device and stored in 
memory prior to interpretation of the control commands to 
begin copying. When the SI and any input or output opera- 
tional labels are assigned to the same physical device, the 
message 



LD INPUT 
NUKEYIN 



is written on the OC and DO device, and the Operator 
Communication routine waits for an operator response. The 
operator should load the input at this point and key in an 
S response to initiate the actual copy procedure. 

If the operational labels are not assigned to the same physi- 
cal devices, interpretation of control commands takes place 
as they are read from SI, and copying begins immediately 
without any message being output on the OC device. 



CALLING COPY 

The COPY routine is requested with the control command 



[UTILITY COPY[, CORE] 



where CORE specifies that, for the first !*COPY or 
!*VERIFY command, the records from the input device are 
stored in core in addition to being copied or verified. For 
subsequent ! *COPY or ! *VERIFY commands, these records 
in core, rather than those on the input device, are used as 
the input source. Following any !*COPY or !*VERIFY 
commands, record and file counts are displayed on the 
DO device. 



After interpretation of the {UTILITY control command, con- 
trol is transferred to the COPY routine which interprets the 
control commands listed below. 



The following operational labels are used by the COPY 
routine in addition to the Utility subsystem operational 
labels: 



Label 



Device 



UI Input device 

X4 Verify device 

Other operational labels may be used by COPY (at the op- 
tion of the user) to specify the input and output devices for 
verifying and copying, respectively. 



COPY CONTROL COMMANDS 

OPLBS The !*OPLBS command identifies the operational 

labels of output devices to be used in COPY requests and 
input for comparison for VERIFY requests, and must follow 
the ! UTILITY command. The input for COPY operations is 
read from UI. For VERIFY operations, X4 is read. UI may 
not be used as a parameter for COPY operations; nor are 
UI and X4 allowed as parameters for VERIFY operations 
that change the device type of UI or X4. Operational 
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labels may be assigned to any device except a random-access 
RAD file. The form of the command is 



/ !*OPLBSoplb , 



,oplb 



where oplb; is the optional label for an output device for 
subsequent !*COPY commands, or an input device for sub- 
sequent !* VERIFY control commands. The oplb parameter 
may not be assigned to device-file number (n <8). 



COPY The !*COPY command causes records from the 

input device (UI) to be copied on the output device (speci- 
fied in the J*OPLBS command) until the requested number 
of !EODs or file marks has been read and copied, or until 
the specified number of records has been copied. The form 
of the command is 

!*COPYtype[,number][,FORM][,size][,BIN] 



wh« 



type is R if the number parameter refers to records, 

or F if the number parameter refers to files. 

number has different meanings, depending upon 
the type parameter that precedes it. If the type 
parameter is R, "number" is the number of records 
to be copied, but refers to logical records for a 
blocked, sequential -access file. If "type" is F, 
"number" is the number of files to be copied, or 
is ALL, indicating that all files should be copied 
until two consecutive EOD images or file marks 
are copied. If "type" is F and any of the input/ 
output devices is a sequential -access RAD file, 
"number" is 1 or it is omitted. If the number pa- 
rameter is omitted, one record or file is copied. 

FORM applies only if data is being copied onto 

the line printer or keyboard/printer. If the FORM 
parameter is omitted, single spacing of printed 
output is the format. If FORM is used, the first 
character of each record is used for format control 
and is not printed. 



specifies the maximum number of bytes in each 
record. If data is being copied to or from a 
sequential -access RAD file, "size" is the maximum 
logical record size and must be an even number. 
If "size" is omitted, all records are read and written 
in the standard record size (120 bytes). An !EOD 
card will not be recognized by M.-WRITE if an odd 
byte count is specified or if a byte count of less 
than four bytes is specified. 



BIN if omitted, mode (BIN or EBCDIC) is determined 
according to byte 1 of the record. If present, all 
copying is done in binary, either with the count 
specified in "size" or the standard record size 
(120 bytes) by default. 



VERIFY The !*VERIFY command requests comparison of 

data on the X4 device with data in core (CORE option) or 
with data from devices specified in the !*OPLBS control 
command. The form of the command is 



!*VERIFYtype[,number][,size][,BIN] 



The parameters are defined as for the !*COPY control 
command. 

Note: UI must not be used on an !*OPLB command with 
VERIFY. 

Before the !*VERIFY control command is issued, it is assumed 
that all files have been repositioned, if necessary, by use 
of !*REWIND and other file positioning control commands 
(described in "Control Function Commands"). The entire 
verification process is completed when the number of files 
or records for verification has been compared. 



DUMP ROUTINE 

The DUMP routine is used to dump records or files onto an 
output device in either hexadecimal or EBCDIC format. 

DUMP uses M:READ and MrWRITE for all input/output. If 
no mode or the EBCDIC mode is specified for dumping, all 
records are dumped according to the contents of the first byte 
of each record. Any record having a first byte of X'lC, 
X'3C, X'9F', X'BF 1 , X'DF', X'FF, X'00', or X'78' is 
assumed to be a binary record containing 120 bytes, and is 
dumped with each data word being represented in EBCDIC 
as a 4— digit hexadecimal number. Any record that does not 
contain one of these characters in its first byte is assumed 
to be in EBCDIC and is dumped as such. 

The user has the option to specify the byte count for paper 
tape record input, since M:READ pads all EBCDIC records 
with trailing blanks so that they appear to be fixed length 
in memory. 



The HEX option for dumping should be used to dump non- 
standard binary records. The option causes ail records that 
are to be dumped to be read in binary and dumped with each 
data word represented in EBCDIC as a four-character hexa- 
decimal number. Since no editing is done when a binary 
read is specified, NL, EOM, and tf are not interpreted as 
editing characters. !EOD is recognized as a file mark. 
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DUMP OPERATIONAL LABELS 

The DUMP routine uses the following operational labels: 
Explanation 



Label 
SI 
LO 
UI 



Device for input commands. 

Output device for dumping. 

Input device for dumping, unless some other 
input device is specified. 

DUMP OPERATING CHARACTERISTICS 



If both SI and DUMP input are assigned to the same device, 
all of the control commands on the SI device are read and 
stored in memory before interpretation of the commands and 
dumping of the input tape begins. When this occurs, the 
message 



LD INPUT UI,ddnn 
NUKEYIN 



is written on the OC and DO device. The operator mounts 
the input tape and keys in an S response to continue. 

If SI and the tape device to be dumped are not assigned to 
the same device, no message is written and control com- 
mands are interpreted as they are read. The DUMP control 
commands are then listed on DO and dumping is performed. 



CALLING DUMP 

The DUMP routine is requested with the control command 



[UTILITY DUMP[, oplb] 



where oplb is the operational label of the input devoce. If 
oplb is omitted, the operational label is assumed to be UI. 



DUMP CONTROL COMMAND 

DUMP The !*DUMP command causes records to be read 

from UI and written on the LO device in the specified mode 
until an !EOD or file mark is read, or the specified number 
of records has been read. The form of the command is 



!*DUMP [number] [, mode] [,: 



n 



where 



number is a decimal integer. Only the specified 
number of records is dumped. If "number" is 
omitted, the file is dumped to an EOF or file mark. 



If "number" is ALL, the dump is performed to 
double file marks or !EODs. 

mode indicates that all records on UI, regardless 

of the content of the first byte of each record, are 
written on the LO device in the mode specified. 
"Mode" is HEX for hexadecimal and EBCDIC for 
EBCDIC. If omitted, EBCDIC is assumed. 

size specifies the maximum number of bytes to be 

read in each record. If the dump "input" is a 
sequential -access RAD file, the size parameter 
must be an even number. For a blocked sequential- 
access file, "size" is the maximum logical record 
size. If it is omitted, the standard record size is 
used . 



OBJECT MODULE EDITOR ROUTINE 

The Object Module Editor is designed to maintain files con- 
taining sets of Standard Sigma 2/3 Object Language mod- 
ules. It generates or updates files by inserting and deleting 
object modules according to the program name in the start 
module item for each module. For each output file written, 
a list of module names is printed in the order of their 
appearance. 

Object Module Editor is also used to list files containing 
object modules and to verify that the input object records 
contain no checksum or sequence errors. 

A binary object module is defined as a sequence of binary 
records in Sigma 2/3 Standard Binary format, each of which 
begins with a nonblank name item and terminates with a 
record whose first byte is X'9F' (END card) indicating that 
the record contains an end item. 

A set consists of one or more object modules and is termi- 
nated by a file mark or !EOD. A tape may contain one or 
more sets and is terminated by double file marks or !EODs. 
Only one set of object modules can be contained in a 
sequential -access RAD file. 

Note that the Object Module Editor routine does not main- 
tain the object modules in the System Library and User 
Library areas on the RAD. These permanent areas are main- 
tained via the RAD Editor (see Chapter 8). 



OBJECT MODULE EDITOR OPERATIONAL LABELS 

The Object Module Editor uses the following operational 
labels: 

Label Explanation 

BI Device from which binary object modules 

are to be inserted. 

LO Device for listing either UI or UO object 

module names. 



90 10 37F-l(3/72) 



Object Module Editor Routine 105 



Label Explanation 

UI Input - device. 

UO Output device. 



After entering the modify mode, the Object Module Editor 
operates as follows: 

If any two of the operational labels SI, BI, and UI are as- 
signed to the same device, Object Module Editor follows 
the steps below: 



OBJECT MODULE EDITOR OPERATING CHARACTERISTICS 

Object Module Editor operates in two modes: list and 
modify. 



t_ iL_ i: -j. i_ __l.. I it :, i 

ill me iisi iiiuuc, \j\ny ui is icuu. 



Tl 



modules are printed on LO, and the checksum and sequence 
for each record are verified. After interpreting the !*LIST 
control command, the Editor checks if any two of SI, BI, 
and UI are assigned to the same device. If so, the message 



LD LIST 
UUKEYIN 



is written on OC. The operator responds by preparing UI 
and keying in an S response. Listing of the modules 
proceeds. 



If no two of the labels SI, BI, or UI are assigned to the 
same device, control commands on SI are interpreted as 
they are read and are written on DO. If the UI device is 
assigned to a sequential -access RAD file, the Object Mod- 
ule Editor leaves the list mode after reading the end-of-fi I e. 



In the modify mode, any modules to be inserted are read 
from the BI device and written on UO, as indicated by the 
SI control commands. If there are input files to be updated, 
they are read from UI. The names of all object modules 
written on UO are listed on LO. The object modules on 
BI must be in the same order in which they are to be in- 
serted on UO. 



1. Interpretation of control commands begins. If any 

object modules are to be inserted, and if SI and BI are 
assigned to the same device, the SI device is read 
until an !EOD is encountered and the message 



3. 



LD INSERTS 
HUKEYIN 



is written on OC and DO. The operator loads the mod- 
ules to be inserted on the BI device and keys in an S 
response. If SI and Blare assigned to different devices, 
no message is written. The Editor then reads in all the 
modules on BI until either an !EOD or any other record 
with a first byte different from X'FF' or X'9F' is read 
from BI. Blank records are ignored. 

2. If there are input files to be updated, the message 



LD INPUT 
HUKEYIN 



is written on OC and DO. The operator must prepare 
UI and key in an S response. 

The mode modification control commands are inter- 
preted, causing updating or generation to proceed. 
Each control command is listed on DO as it is interpreted. 



If no two of the operational labels SI, BI, and UI are as- 
signed to the same device, control commands from SI are 
read and interpreted dynamically. Records are read from 
BI and UI and written on UO in response to each mode mod- 
ification control command. Every control command read 
from SI is listed on DO. 



The Object Module Editor operates in the "prestore" mode 
(reading and storing commands before interpreting) when 
the conditions shown below occur; otherwise, the Editor 
operates dynamically. 



Object Module Editor uses M.-READ and M:WRITE to perform 
all input/output. Each object module is identified by the 
program name stored in the start module item. No modules 
with blank names are even written on the UO tape. 



Operational Labe 
Assigned to Same 


Is 
Device 


Prestored Data 


SI, BI 






SI 


SI, UI 






SI 


BI, UI 






BI 


SI, BI, 


UI 




SI, BI 



CALLING OBJECT MODULE EDITOR 

The Object Module Editor is requested with the control 
command 



A 



UTILITY OMEDIT 
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After interpretation of the 1UTILITY control command, 
control is transferred to the Object Module Editor routine. 
The control command and options available to OMEDIT are 
described below. 

Object Module Editor begins reading control commands 
until an !EOD or an !*ENDis read, which terminates 
the SI input. 



INSERT The !*INSERT command causes an object module 

to be inserted and is effective only in the modify mode. 
The form of the command is 

!*INSERT name. [, name.] 



where 



OBJECT MODULE EDITOR CONTROL COMMANDS 

LIST The !*LIST command causes the Editor to enter the 
list mode. The names of the object modules on UI are read 
and listed on LO. Any checksum errors detected cause 
error messages to be written on LO, but listing continues. 
If the record is an IEOD, it is listed. If two consecutive 
!EODs are encountered, the Editor leaves the list mode and 
the next control command is interpreted. The form of the 
command is 



LIST 



MODIFY The !*MODIFY command indicates that ob- 

ject modules are to be output on the UO device and causes 
the Editor to enter the modify mode. The modify mode ter- 
minates when an !EOD or !*LIST control command is inter- 
preted from SI, or two !EODs from BI or UI. The form of 
the command is 



™- Q] 



/here 



GEN is an optional parameter indicating that ob- 

ject modules are to be selectively input from BI 
and that files are to be generated on UO. UI is 
not read. The control command !*MODIFY GEN 
may be followed only by !*INSERT control com- 
mands (GEN implies !*INSERT) used to define the 
elements to be selectively copied from BI to UO. 
No !*DELETE control commands may be used in 
the GEN mode. 

INSERT must be specified if insertions from BI are 

to be read. If BI and UI are assigned to the same 
physical device, the complete BI file (up to an 
!EOD) will be prestored. Modules can be selected 
from BI by names on the !*INSERT control com- 
mands. The inserts must be in proper order. This 
command is used to update (input both !*INSERT 
and !*DELETE commands) UI and to write UO. 

Note: If INSERT and GEN are omitted from the !*MODIFY 
control command, only !*DELETE control commands 
may be input. 



name'] is the name (up to eight EBCDIC characters) 

of the object module to be inserted. 

name2 is the name (up to eight EBCDIC characters) 

of the object module on UI that the name] object 
module must follow. If name2 is omitted, the 
name] module is written following the module 
previously written on UO. 

Modules to be inserted from BI must be in the same order as 
in the INSERT control commands. If GEN is specified on 
the MODIFY command, only the name] parameter in the 
INSERT command is required; if a name2 is specified, it is 
ignored. 



DELETE The DELETE command causes object modules to 

be deleted and is effective only in the modify mode. The 
form of the command is 



!*DELETE name. [,name.] 



/here 



name] is the program name (up to eight EBCDIC 

characters) of the first or only module on UI to be 
deleted. 

name2 is the program name (up to eight EBCDIC 

characters) of the last module on UI to be deleted, 
If absent, only one module is deleted. 

The !*DELETE control command must name modules in the 
same order as their occurrence on UI. 



RECORD EDITOR ROUTINE 

The Record Editor is used for source editing by record num- 
ber from any sequential device to any other sequential de- 
vice. Record Editor provides the following capabilities: 

1 . Generates files containing source data. 



2. Lists files containing source images in addition to 
associated line numbers. 



3. Modifies files containing source images, 
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RECORD EDITOR OPERATIONAL LABELS 

The following operational labels must be assigned in addr 
tion to the standard Utility program operational labels: 

Label Explanation 

SI Input device for control commands. 

LO Output device for listing source images. 

UI Input device. 

UO Output device. 



RECORD EDITOR OPERATING CHARACTERISTICS 

The Record Editor routine operates in two modes: list 
and modify. 

In the list mode, the Editor reads source images from UI and 
lists them on the LO device. It associates each image with 
a decimal line number, starting with 1. 

In the modify mode, the Editor either updates or generates 
files on the UO device. 

Record Editor uses M:READ and M:WRITE to perform all 
input/output. Therefore, all the paper tape editing and 
keyboard/printer editing that is standard to these routines 
is performed. 



CALLING RECORD EDITOR 

The Record Editor is requested with the following control 
command 

'UTILITY RECEDIT 



After interpretation of the ! UTILITY control command, con- 
trol is transferred to Record Editor, which begins reading 
control commands. 



RECORD EDITOR CONTROL COMMANDS 

A command requesting either the list or modify mode must 
immediately follow the 'UTILITY command. All other con- 
trol commands are interpreted as subcommands under each 
mode. If a binary record is read from UI, the following 
message is written on OC and DO: 



file mark, or !EOD causes the line numbering to restart 
with 1. The form of the command is 



MODE ERR UI, device 
NUKE YIN 



LIST The !*LIST command (list mode) causes the previous 
mode to terminate. The source files are read from UI and 
listed on LO. Each EBCDIC source image is listed along 
with an associated line number up to and including the first 
!EOD source image or file mark read. After the required 
number of files has been listed, another control command 
is read from the SI device. Each !*LIST control command 



!*LIST [number] 



where number indicates the number of files to list. Listing 
continues until two consecutive !EODs are encountered or 
the specified number of files is listed. If "number" is omit- 
ted, one file is listed. If UI is assigned to a sequential- 
access RAD file, the number parameter must not be greater 
than 1. 

A !*MODIFY, !*END, or !EOD control command causes 
t*ii© list mods to tsfminofs 

MODIFY The !*MODIFY command informs the Record 

Editor that files are to be either generated or updated. It 
terminates the previous mode and initiates the modify mode. 
The form of the command is 



!*MODIFY [LIST] [, GEN] 



fhere 



LIST indicates that a listing of records deleted or 

inserted will be produced on LO. If LIST is the 
only parameter used, the listing will contain the 
UI line numbers (the number deleted or the num- 
ber preceding the one inserted). If GEN is also 
present, the UO line numbers will be listed. 

GEN indicates that records are to be read from SI 

(there is no input on UI) and written on UO. If 
updating is to be performed (that is, there is input 
to be read from U^ tki*» nnrnmeter field is left emotv 

IW WV ■ VVtW II VIII w*^ • • • _ p* « . -* _J.1_. - . — . _S . _ . - - -V p- ^ _ 

The modify mode is terminated whenever a !*LIST, 
!*MODIFY, !*END, or !EOD control command is input 
from SI. When the modify mode is terminated and GEN is 
specified, an !EOD or file mark is written on UO. When 
the modify mode is terminated and GEN is not specified, 
the remaining source images of the file on UI (until an EOD 
is encountered) are written on UO, followed by an EOD or 
file mark. 

DELETE The !*DELETE command causes the indicated 
record source images to be deleted and is effective only in 
the modify mode. The form of the command is 



!*DELETE number 



]l> 



umber-] 



number] is the line number of the first (or only) 

source image to be deleted. 

number2 is the line number of the last source image 

to be deleted. 
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INSERT The !*INSERT command causes record source 

images from SI to be added to UI and written onto UO, and 
is effective only in the modify mode. The form of the com- 
mand is 

!*INSERT number 



where number is the line number that the insertions are to 
follow. If a line number of (zero) is used, the insertions 
will precede the first line. 

Every source image on SI following the !*INSERT control 
command is inserted until a new Record Editor control com- 
mand is encountered. 

CHANGE The !*CHANGE command causes the indicated 

source images to be deleted, and the source images fol- 
lowing the CHANGE command to be written on UO. The 
command is effective only in the modify mode. The form 
of the command is 



I* 



CHANGE number^, number,-] 



number] is the line number of the first source image 

to be deleted. 

number is the line number of the last source image 

to be deleted. If omitted, only one source image 
will be deleted. 

Following the !*CHANGE control command, every source 
image on SI is inserted until another Record Editor control 
command is encountered. 

SEQUENCE EDITOR ROUTINE 

The Sequence Editor edits EBCDIC card images by sequence 
number. It is more flexible than the Record Editor in that 
multiple programs or sections of programs may be updated 
and sequenced individually within single or multiple files. 
It provides greater protection from updating in an incorrect 
sequence, or from accidentally updating the wrong program. 
Another feature of the Sequence Editor routine is that update 
card images may be inserted without changing the existing 
sequence numbers. Thus, update decks may be cumulative 
and will reflect the development of a source program. 

The Sequence Editor is primarily intended for installations 
where EBCDIC source programs are kept on magnetic tape. 
It is somewhat impractical for paper-tape-oriented systems 
or systems without a line printer. 

Editing is accomplished by designating columns 73 through 80 
of a source card image as the "sequence field". This field 
consists of two parts, the ident and the sequence number. 

The optional ident is that portion of the sequence field that 
uniquely identifies a program or program segment. If de- 
fined, the ident begins in column 73 of the card image and 
is from one to six alphanumeric characters in length. 



The required sequence number is that portion of the sequence 
field that is sequenced numerically. It consists of from two 
through eight decimal characters and ends in column 80 of 
the card image. The user can specify the value by which 
successive sequence numbers are incremented. In general, 
a large sequence increment will allow larger insertions 
without affecting the existing sequence numbers. 

Together, the ident and sequence number must not total 
more than eight characters. Any unused columns will be 
between the ident and the sequence number and will be 
ignored by the Sequence Editor. 

SEQUENCE EDITOR OPERATIONAL LABELS 

The following operational labels are used by the Sequence 
Editor routine: 

Label Explanation 

SI Update data (includes card images and 

control commands). 

LO Annotated listing of added and deleted 

card images. 

UI Input device. 

UO Output device. 

Device, above, refers to any permanent storage device such 
as magnetic tape, paper tape, or RAD (single sequential 
file). Note that LO should not be assigned to the keyboard/ 
printer, because the sequence number portion of the print- 
out is truncated on that device. 



SEQUENCE EDITOR OPERATING CHARACTERISTICS 

The Sequence Editor performs two separate and distinct 
functions: generates files on UO from source images input 
on SI, and updates files from UI onto UO, taking updates 
from SI. Only one of these functions can be performed per 
call to the Sequence Editor (SEQEDIT). 

The file generation (GEN) function is used to create the 
permanent files initially. It is recommended that files be 
sequenced as they are generated to avoid an update pass at 
a later stage. The user can generate one file (terminated 
by an !EOD or an !*END from SI) wherein a single file mark 
is written on UO, or multiple files (terminated by two !EODs 
or !*ENDs from SI) wherein two file marks are written onto 
UO and UO is backspaced one file. 

The update function is used toupdate Ulbyreplacing, delet- 
ing, or inserting card images from SI and writing the updated 
files onto UO. The files can be resequenced as they are 
written. The user can update one file (terminated by an EOF 
from UI) wherein an EOF is written onto UO, or all files 
(terminated by logical end-of-tape or two EOFs from UI) 
wherein two file marks are written on UO and UO is back- 
spaced one file. With the ALLoption, it is not necessary to 
update each file, but all files will be copied onto UO. 

Files can be sequenced as they are generated or updated. 
Sequencing is a separate operation in that the card images 
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are sequenced as they are written on UO. Thus, it is possible 
to update an existing file byidentand sequence number while 
placing a new identand sequence number on the update file. 

CALLING SEQUENCE EDITOR 

The Sequence Editor is requested via the control command 
/\ UTILITY SEQEDIT,[GEN][,IGN]LaLL] 



where 

GEN indicates that output files are being gener- 

ated on the UO device and that there are no input 
files to be updated. 

IGN indicates that SI sequence errors are to be 

ignored if UO is being generated or that UI se- 
quence errors are to be ignored if UI is being 
updated. If IGN is used, no sequence error mes- 
sages are printed. 

ALL indicates that the GEN function is to continue 

until two !EOD or !*END cards are encountered 
from SI, or that the update function is to continue 
until two EOFs are encountered from UI. 

The leading comma must be specified. 

The Program Executive transfers control to the Sequence 
Editor, which interprets and validates the parameters. If 
illegal parameters are input, the Utility program aborts 
with a code of UT. If this is an update (the GEN option 
was not specified), the following message is output on OC 
and DO: 



LD INPUT UI, device 
MUKEYIN 



SEQUENCE EDITOR CONTROL COMMANDS 

IDENT The !*IDENT command defines the breakdown 

of the sequence field into the ident and the sequence num- 
ber. It applies to card images from UI and SI only. If used, 
it should precede the update cards to which it applies. If 
omitted, the ident field is considered empty and the se- 
quence number is eight characters in length. The !*IDENT 
control command is used whenever it is necessary for the 
Sequence Editor to know the size and content of the ident 
field (that is, when UI contains multiprogram files or single- 
program files with nondecimal characters in the sequence 
field). It is not to be used when files are being generated. 
The form of the command is 

!*IDENT [ident][, sequence-number] 



where 



sequence field starting from column 73. If "ident" 
is omitted, the ident field does not exist. 

sequence number is an integer n2 (2 <n2< 8) that 

specifies the number of characters in the sequence 
number subset of the sequence field ending in 
column 80. If omitted, sequence number is set 
equal to the difference (8 - ident). 

The user should note that if a nonzero ident field has been 
specified on an !*IDENT command, the idents on each card 
image from UI must match exactly or resequencing will be 
suspended when the first nonmatching ident is encountered. 
Hence, if UI is known to have nonmatching idents (for ex- 
ample, a file that has never been sequenced or one that has 
been updated and contains some blank sequence fields), a 
separate sequence operation should be performed (without 
a simultaneous update) specifying an empty ident field. 

Replacement. The update card itself, rather than a control 
command, is used to replace a card image from UI. The 
sequence number on the update card must equal the sequence 
number on the UI card image to be replaced. The card im- 
age from UI and the message "DELETED", followed by the 
card image from SI and the message "INSERTED" are output 
on LO. 

Insertion. The update card itself, rather than a control 
command, is used to insert a card image on UO. The se- 
quence number on the update card must be between the 
sequence number of the two continuous UI card images 
where the update card is to be inserted. The card image 
from SI and the message "INSERTED" are output on LO. 
Cards without sequence numbers are inserted immediately 
following the sequenced card preceding them. Thus, a 
large block of card images can be inserted by placing the 
proper sequence number on the first card only. The nonse- 
quenced cards will be written on the output tape without 
sequence numbers. It is recommended that the tape be re = 
sequenced as it is being updated if unsequenced cards are 
inserted. 

DELETE The !*DELETE command deletes one or more card 
card images from UI. Nonsequenced cards can only be de- 
leted by deleting from the last sequenced card preceding 
the nonsequenced card(s) up to and including the next se- 
quenced card. Deleted card images are listed on LO. The 
form of the command is 



73 



80 



'DELETE [sequence field,] 



sequence field. 



ident is an integer n] (0 < n] < 6) that specifies 

the number of characters in the ident subset of the 



sequence field2 indicates that the images are to be 

deleted from the ident and/or sequence number in 
sequence field] up to and including the ident and/ 
or sequence number in sequence field2« 

sequence field] contains the ident and/or sequence 

number of the first or only card image to be de- 
leted from UI. This parameter is required. 
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SUPPRESS The !*SUPPRESS command is identical to the 

!*DELETE control command except that no deletion card 
images are listed on LO. The form of the command is 



73 

H— 



80 

-h 



!*SUPPRESS [sequence field,] 



sequence fie Id 1 



SEQUENCE The !*SEQUENCE command is used to 

resequence columns 73 through 80 of the card images on 
UO. Only one program can be resequenced with each 
!*SEQUENCE command. Therefore, resequencing is sus- 
pended when either a file mark or a card image with a 
sequence number identifying a new program is written on 
the output tape. Resequencing is also suspended when 
another !*SEQUENCE command is executed; therefore, 
parts of a program as well as entire programs can be rese- 
quenced. The form of the command is 



73 



80 



/ ' h 

X!*SEQUENCE seq. field, , increment seq.fiekL 



where 



sequence field2 contains the ident and/or sequence 
number of the first resequenced card image to be 
written on the output tape and does not neces- 
sarily have the same fields as defined in the 
! *IDENT command. (The ! *IDENT command de- 
finessequence fields for the input tape and update 
data only.) If omitted, resequencing is suspended. 

increment is the resequencing increment number. 
If omitted, an increment of 10 is used. It is the 



responsibility of the user to ensure that the se- 
quence number does not get incremented past the 
size of the sequence number field. No warning 
is issued if this overlap occurs. 

sequence field] contains the ident and/or sequence 

number from UI at which the ! *SEQUENCE 
command becomes effective. If omitted, the 
1*SEQUENCE command takes effect with the 
next card image to be written on UO. 



UTILITY ERROR MESSAGES 

Unless otherwise noted, the following definitions apply in 
error messages given in Tables 21 through 26: 

Code Explanation 

oplb Operational label of the device. 

device Device type or physical device number. 

The operator response to !!UKEYIN is 

Code Meaning 



Continue 
Abort 



When an irrecoverable error occurs, the Utility program 
aborts. For an irrecoverable input/output error on OC or 
DO, the code in the abort message is the operational label 
of the device. For- other operational labels, the irrecover- 
able input/output message is written. Abort returns, due 
either to error or X operator responses, cause UT to appear 
in the abort message. 



Table 21. I/O Error Messages 



Message 


Meaning 


BOToplb, device NUKEYIN 


An attempt has been made to backspace over the magnetic tape load point 
or the beginning-of-tape of a RAD file. 


CAL SEQ ERR 


The Utility Executive has encountered a calling sequence error on a return 
from M:READ/M:WRITE. One reason may be an attempt to copy a record 
with an odd byte count onto the RAD (may occur with BCD 7-track tapes). 
See M:READ status returns in Chapter 4 of this manual. 


EMPTY oplb, device NUKEYIN 


Manual intervention is required (the device is in the manual mode or no 
device is recognized). 


EOF op lb, device !!UKEYIN 


An unexpected tape mark, end-of-file (RAD), or !EOD has been read from 
magnetic tape, cards, paper tape, keyboard/printer, or RAD file. 


EOT oplb, device IIUKEYIN 


The end-of-tape mark on a magnetic tape or RAD file has been sensed. 
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Table 21. I/O Error Messages (cont. ) 



Message 


Meaning 


IL RAD SEQ oplb, device M UKEYIN 


An operational label was assigned to a random-access RAD file, or an 
attempt was made to skip, read, or write more than one RAD file. 


INV I/O OP oplb, device MUKEYIN 


An input/output operation is not meaningful for the requested device. 


1NV OPLB oplb, device ! IUKEYIN 


The operational label is not valid. The "oplb, device" portion of the 
message may contain invalid data if input/output is attempted for an 
operational label not recognized by the Monitor. 


I/O ERR oplb, device 


The input/output calling sequence is in error, incorrect length is 
specified, or no input/output is pending for a check operation. The 

I IfTliK/ r\rs\nrrtm rvr\r\r¥c 

~ / F"~»- — J -« 


UNRECOV I/O oplb, device ! IUKEYIN 


An irrecoverable input/output error has occurred after the maximum 
number or retries has been unsuccessfully attempted. 


WRITE PRO oplb, device MUKEYIN 


An attempt has been made to write on a write-protected magnetic tape 
or RAD file. 



Table 22. Control Function Command Error Messages 



Message 


Meaning 


FSKIP Command 


DEOF oplb, device ! IUKEYIN 


Two consecutive file marks were encountered before the required number 
of files had been passed. 


EOT oplb, device MUKEYIN 


The end-of-tape was encountered before the required number of files has 
been passed. 


IL RAD SEQ oplb, device ! IUKEYIN 


The number parameter is not I and "oplb" is assigned to a sequential- 
access RAD file, or the oplb parameter is assigned to a random-access 
RAD file. 


INV OPLB MUKEYIN 


The operational label identifies an invalid device. 


PARAMERR MUKEYIN 


The oplb parameter is missing, or the number parameter is nonnumeric or 
greater than 32, 767. 


RS KIP Command 


EOF oplb, device MUKEYIN 


An !EOD or file mark was encountered before the required number of 
records was passed. 


EOT oplb, device MUKEYIN 


An end-of-tape was encountered before the specified number of records 
was skipped. 


IL RAD SEQ oplb, device ! 'UKEYIN 


The oplb parameter is assigned to a random-access RAD file. 


INV OPLB MUKEYIN 


The oplb parameter identifies an invalid device. 


PARAMERR MUKEYIN 


The oplb parameter is missing, or the number parameter is nonnumeric or 
greater than 32, 767. 
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Table 22. Control Function Command Error Messages (cont. ) 



Message 


Meaning 


FBACK Command 


BOT oplb, device NUKEYIN 


The beginning-of-tape was encountered before the required number of 
files had been passed. 


DEOF oplb, device NUKEYIN 


Two consecutive file marks were encountered before the required number 
of files was backspaced. 


IL RAD SEQ oplb,device HUKEYIN 


The oplb parameter was assigned to a random-access RAD file. 


INV OPLB oplb, device HUKEYIN 


The operational label identifies an invalid device. 


PARAMERR HUKEYIN 


The operational label parameter is missing or contains more than two 
characters, or the number parameter is nonnumeric or greater than 32, 767. 


RBACK Command 


BOT oplb, device HUKEYIN 


The beginning-of-tape was encountered before the requested number of 
records had been passed. 


EOF oplb, device HUKEYIN 


A file mark was encountered before the requested number of records had 
been passed. 


IL RAD SEQ oplb, device HUKEYIN 


The oplb parameter was assigned to a random-access RAD file or a 
compressed EBCDIC RAD file. 


INV OPLB oplb, device HUKEYIN 


The operational label identifies an invalid device. 


PARAM ERR HUKEYIN 


The operational label parameter is missing or contains more than two 
characters, or the number parameter is nonnumeric or greater than 32,767. 


REWIND Command 


IL RAD SEQ oplb, device HUKEYIN 


The oplb parameter is assigned to a random-access RAD file. 


PARAMERR HUKEYIN 


The oplb parameter contains more than two characters. 


UNLOAD Command 


IL RAD SEQ oplb, device NUKEYIN 


The oplb parameter is assigned to a random-access RAD file. 


INV OPLB oplb, device HUKEYIN 


The oplb parameter identifies an invalid device. 


PARAM ERR HUKEYIN 


The oplb parameter was missing or contained more than two characters. 


WEOF Command 


EOT oplb, device HUKEYIN 


The end-of-tape was encountered. 


IL RAD SEQ oplb, device NUKEYIN 


The oplb parameter was assigned to a random-access RAD file. 


INV OPLB HUKEYIN 


The oplb parameter identifies an invalid device. 


PARAMERR NUKEYIN 


The oplb parameter is missing. 
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Table 22. Control Function Command Error Messages (cont. ) 



Message 


Meaning 


PRESTORE Command 


CORE OVFLO 


Available core memory has overflowed. The Utility program aborts. 


PRE ERR MUKEYIN 


The !*PRESTORE command did not follow immediately after the 
FUTILITY command. 


PRE OVFLO 


The RAD prestore file on X5 has overflowed. The Utility program aborts. 


ASSIGN Command 


ERRFRGD MUKEYIN 


An attempt has been made to assign a background operational label to a 
foreground operational label, device-file number, or RAO file. 


ERROPLB1 HUKEYIN 


The operational label to be assigned is invalid. 


ERROPLB2 HUKEYIN 


An attempt has been made to assign one operational label to an invalid 
or undefined operational label or RAD file. 


NO SPARES ! IUKEYIN 


An attempt has been made to define a new background operational label 
but no room is available in the corresponding table. 


ERR AREA HUKEYIN 


An invalid RAD area name has been used. 


OPLB TABLE OVFL ! IUKEYIN 


An attempt has been made to define more than eight unique operational 
labels. The assign will be successful, but the operational label will not 
be used as an output device. 



Table 23. COPY Error Messages 



Message 


Meaning 


CORE OVFLO 


The memory area used for storing input records (when the CORE option on 
the IUTILITY COPY command is used) has overflowed. The Utility pro- 
gram aborts. 


IL RAD SEQ oplb, device HUKEYIN 


An attempt has been made to copy or verify from or to a random-access 
RAD file. 


OPLB TABLE OVFL ! IUKEYIN 


An attempt has been made to input more than eight operational labels. 
Only the first eight unique labels on an !*OPLB card will be entered 
in the operational label table. 


IDEOF oplb, device 1 
IEOT oplb, device I IUKEYINJ 


An end-of-tape, or two consecutive tape marks or !EODs were detected 
on X4 or UI before the number of files requested has been compared. 


EOF oplb, device HUKEYIN 


An IEOD or file mark was detected on X4 or UI before the number of 
records requested had been compared. 


VERIFY ERR oplb, device 


An error has been found by the verification process. When a verification 
error occurs, the COPY routine terminates execution of the !*VERIFY 
command for that device, but continues verification on other input 
devices. If an error is detected on every input device, the VERIFY 
function is aborted. 
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Table 24. Object Module Editor Error Messages 



Message 


Meaning 


BLNK NAME oplb,device IIUKEYIN 


A blank name was input. 


CKSM ERR oplb,device ! ! UKEYIN 


A checksum error was detected on a record read from UI or BI. 


EOT oplb,device ! ! UKEYIN 


An end-of-tape was encountered on BI or UI. 


ILLEG BIN oplb,device IIUKEYIN 


The first byte of a record read from UI or BI did not contain X'FF 1 
orX'9F'. 


NO name oplb,device ! ! UKEYIN 


Two consecutive ! EODs or tape marks on UI, or one ! EOD or tape mark 
on BI were encountered during the editing process before the desired 
number of modules had been copied (where "name" is the program name 
not found). 


NO name UI,device ! ! UKEYIN 


Two consecutive !EODs or file marks (one end-of-file for a sequential- 
access RAD file) are read from UI before the Object Module Editor has 
inserted, replaced, or deleted all requested modules. 


SEQ ERR oplb,device ! ! UKEYIN 


A sequence error was detected in a record read from UI or BI. 



Table 25. Record Editor Error Messages 



Message 


Meaning 


! ! LD LIST UI,device 


Both SI and UI are assigned to the same device. The operator responds 
by mounting the tape to be listed and changes the state of the device. 


LD INPUT UI,device !! UKEYIN 


The modify mode was entered and updating is to be performed. The 
operator responds by mounting the tape to be input and keying-in an 
S response on OC to continue. 


INV CTRL ! ! UKEYIN 


A ! *MODIFY control command was interpreted from SI when the Record 
Editor was not in the modify mode. 
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Table 26. Sequence Editor Error Messages 



Message 


Meaning 


DELETE ERR !! UKEYIN 


No UI card images were found in the block to be deleted (for ! *DELETE 
and ! *SUPPRESS commands). 


DEOF ULdevice!! UKEYIN 


The program to be updated was not encountered on the input tape before 
the logical end-of-tape. An S response causes the Sequence Editor to 
return to RBM. All updating done prior to this point has been written, 
along with the logical end-of-tape marker on the output tape. 


PARAMERR UUKEYIN 


Case 1. Update data from SI contains an illegal sequence number; that 
is, a nonnumeric character. An error alarm is also listed on LO. 

Case 2 5 A necessarv control command parameter was omitted. 

Case 3. The ident parameter (on an !*IDENT card) is greater than 6, the 
sequence number parameter is less than 2, or the sum of the two 
parameters is greater than 8. 


SEQ ERR oplb,device ! ! UKEYIN 


A sequence error was found in either the update data or input tape. In 
this case, the oplb parameter refers to either SI or UI. An error alarm is 
also listed on LO. 


UNRECOV I/O UI,device ! ! UKEYIN 


An irrecoverable read error has occurred on UI. The partial card image 
input and the message "UI IGNORED RECORD FOLLOWS xxxxxxxx" 
(when xxxxxxxx is the previous nonblank UI ident and/or sequence 
number) is output on LO. 


UNRECOV I/O UO,device !! UKEYIN 


An irrecoverable write error has occurred on UO. The card image to be 
output, and the message "UO RECORD OMITTED" or "UO FILE MARK 
OMITTED", are output on LO. 
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10. PREPARING THE PROGRAM DECK 



The following examples show some of the ways program 
decks may be prepared for RBM operation. Unless stated 
otherwise, standard default cases for device assignments 
are assumed. 

EXTENDED SYMBOL EXAMPLES 

ASSEMBLE SOURCE PROGRAM. LISTING OUTPUT 
AND BINARY OUTPUT 



In this example, the source decks are assembled in batch 
mode (BA). In this mode, successive assemblies may be 
performed with a single IXSYMBOL command until a 
double !EOD command is encountered. The parameters 
defined on the IXSYMBOL command will hold true for 
each assembly in the batch. Each assembly will be fol- 
lowed by a Symbol cross-reference (CR). 



!FIN 



\ 



!EOD 



ML 



Source deck 



^ 



IXSYMBOL BO, LO 



UOB 



_y 



In this example, the symbolic input is received from the 
SI device (always defaulted), the binary output is received 
on the BO device, and the listed output is received on the 
LO device. Note that although BO and LO are normally 
default cases, they must be specified if output to the GO 
file (also a default) is not desired. 

ASSEMBLE IN BATCH MODE. LISTING OUTPUT AND 
BINARY OUTPUT WITH SYMBOL CROSS-REFERENCE 



M 



!EOD 



IEOD 



Source deck n 




!EOD (optional) 



Source deck 2 



^ 



A 



!EOD (optional) 



Source deck 1 



<> 



IXSYMBOL BA,LO,BO,CR 



UOB 



ASSEMBLE. LOAD, AND GO FROM USER DEFINED 
OV FILE. LISTING OUTPUT 



!XEQ 



!EOD 



!$ROOT ,,GO 



IOLOAD 



IASSIGN OV=USEROV,UP 



M 



!EOD 



Source deck 



<> 



IXSYMBOL LO,GO 



!JOB 



i 



!EOD 



! # ADD UP,USEROV,4 



IRADEDIT 



! PAUSE KEYIN SY,S 



IATTEND 



UOB 



In this example, the user is defining his own OV file 
through a call to the RAD Editor. After assembly, the OV 
file is assigned to the user defined file. The call to the 
Overlay Loader (IOLOAD) causes it to load the module 
defined on the !$ROOT command to the USEROV file for 
execution. The advantage to assigning the program to a 
user-defined OV file rather than using the RBMOV file is 
that the program can be loaded into core for execution 
repeatedly without reassembly. Conversely, the contents 
of RBMOV cannot be guaranteed to be saved from one job 
to another. 
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ASSEMBLE SOURCE PROGRAM. 
LISTING OUTPUT, LOAD AND GO 



!XEQ 



!EOD 



!$ROOT ,,GO 



IOLOAD 



!EOD 



m 



Source deck 



IXSYMBOL LO,GO 



UOB 




In this example, the binary object module is loaded into 
the RBMGO file located in the System Data area. The call 
to the Over I ay Loader (IOLOAD) causes it to load the mod- 
ule defined on the !$ROOT command to the RBMOV file for 
execution. The double comma on the !$ROOT command 
informs the Loader that the temp, exloc parameter options 
are defaulted. 



BASIC FORTRAN IV EXAMPLES 



COMPILE MULTIPLE PROGRAMS 



M 



!FIN 



!EOD 



Source Deck(s) 



{FORTRAN XP 



2) 







!EOD 



Source Deck(s) 



IFORTRAN LO,XP 



! ASSIGN GO=0 



UOB 




In this example, output to the GO file is not desired in the 
first job, so the GO oplb must be assigned to (see Appen- 
dix E and IASSIGN command writeup in Chapter 2). An 
object listing is desired (LO) and extended precision real 
data is specified. 

The second job will receive a source listing by default and 
extended precision real data is again specified. Since the 
parameters are different on the two IFORTRAN control 
commands, the jobs cannot be run in batch mode. 



COMPILE, LISTING OUTPUT, LOAD AND GO 



M 



!FIN 



IEOD 



Data deck 



!XEQ 




!EOD 



!$ROOT ,,GO 



!$ML 



IOLOAD 



IEOD 



A 



Source deck 



IFORTRAN 



I IATTEND 



UOB 




In this example, the IATTEND command specifies that 
the Monitor is to go into a "wait" state instead of 
aborting the job in case of irrecoverable error (gener- 
ally recommended for "load and go" jobs). Binary out- 
put will be received on both the BO and GO devices 
by default, and standard precision mode is also assumed 
by default. The binary object module is loaded into 
the RBMGO file located in the System Data area. 

The call to Overlay Loader (IOLOAD) causes it to 
load the module defined on the !$ROOT command to 
the RBMOV fiie for execution. The double comma on 
the !$ROOT command informs the Loader that the temp, 
exloc parameter options are defaulted. The Loader is 
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90 10 37F-K3/72) 



requested to output a LONG map (!$ML). The !XEQ 
command causes the executable program to process the 
data deck. 



SEGMENTED PROGRAM EXAMPLES 

ASSEMBLE SEGMENTED BACKGROUND PROGRAM, 
LOAD AND GO 



COMPILE AND EXECUTE FOREGROUND PROGRAM 

This example would be used for debugging purposes only. 



seg 1 



Root (seg 0) 



seg 2 



seg 3 



!XEQ 



!EOD 



!$ROOT ,+1800, GO 



!$TCB+DB0D,+1200 



IOLOAD ,F 



! PAUSE KEYIN FG,S 



A 



!EOD 



FORTRAN source statements 



^ 



! FORTRAN 



'ASSIGN BO=0 



UOB 



In this example, binary output to the BO device is 
suppressed. The IFORTRAN control command specifies 
that the binary output is to be received on the GO file 
by default and standard precision mode is assumed. The 
! PAUSE command permits the operator to key in FG, S 
to access protected foreground memory. The program is 
defined to the Overlay Loader as a foreground program 
( IOLOAD, F) and the COMMON base is set to the 
FWA of the background. The Loader is to create the 
Task Control Block, the first two words of which are 
defined on the !$TCB command. These two words spe- 
cify that the task is to be connected to interrupt loca- 
tion IOD (Integral interrupt number 2, priority level 8, 
within group 0). 



The !$ROOT command specifies that the root is to be 
loaded from the GO file, and will start execution at 
location 1800 in foreground memory. The core image 
form of the program is loaded on the OV file (RBMOV). 
The !XEQ command loads the executable program into 
core. When loaded, the task is armed, enabled, and 
then triggered. 




Given the program tree structure shown above, the sample 
deck setup illustrates a background program with a root and 
three overlay segments. These are assembled and loaded 
into the RBMGO file. The IOLOAD command specifies 
that these three segments are to be loaded, and defines it 
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as a background program (B). The $SEG commands specify 
that segments 1 through 3 are attached to the root, and the 
modules are to be loaded from the RBMGO file to the 
RBMOVfile for subsequent loading into core for execution. 
A load map is output (!$MP). 



LOAD AND EXECUTE MULTIPLE OBJECT MODULES 



Given the sample program tree structure shown above, the 
illustrated deck would load and execute the segmented 
program. The program is loaded from either the device or 
file assigned to the BI operational label. No load map is 
requested (an !$ML, !$MS, or !$MP command could be 
inserted after the IOLOAD command if a map was desired). 
Although the segments could be loaded in any order, the 
proper calling sequence is the responsibility of the user. 



seg 1 



Root 



seg 2 



seg 3 



!XEQ 



!$END 



1 Object module 



!$SEG3,0,BI, 1 



M 



£ 



Object modules 



!$SEG 2,0,BI,2 



| $SEG5,1,BI,1 



1 Obiect module 



MM 



A 



1 Object module 



$SEG 4,1,BI,1 



1 Object module 



seg 4 



seg 5 




$ 



^ 



r 



w... 




<> 



!$SEG 1,0,BI,1 



/zm 



f 



3 Binary object modules 



1 



!$ROOT ,,BI,3 



IOLOAD 5,B 



!JOB 



RAD EDITOR EXAMPLES 



BUILD PUBLIC LIBRARY 



!EOD 



Relocatable binary module 5 



<> 



ml 



Relocatable binary module 2 



Relocatable binary module 1 



!$PUBLIB E,BI,5 



IOLOAD 



IASSIGN OV=PUBLIB,UP 



IEOD 




! # ADD UP,PUBLIB,48,0, R, R 



! # ADD SD, LIBSYM, 20, 0, R, R 



IRADEDIT 



! PAUSE KEYIN SY, S 



UOB 



The Public Library is core resident. In this example, the 
user must create two RAD files to set up the Public Library: 
the LIBSYM file and the PUBLIB file. The LIBSYM file 
contains the Symbol Table for the Public Library and is used 
by the Overlay Loader to satisfy references to the Public 
Library. The PUBLIB file contains the Public Library and 
is booted in with RBM. (RBM must be rebooted to load the 
updated Public Library.) 
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LOAD ROUTINES IN USER LIBRARY 



! # END 

A 

Object module (RMAX ident) 



M 




! # LADDUL,RMAX,B 



Object module (TUU ident) 




! # LADD UL,TUU,E 



M 



Object module (RDATA ident) 




! # LADD UL, RDATA, M 



! # ADD UL,MODULE,50,0,R,R 



! # ADD UL,MDFRF,2,0jy* 



! # ADD UL,BDFRF,2,0,R,R 



_w 



! # ADD UL,EDFRF,2,0,R,R 



! # ADD UL, EBCDIC, 6,0,R,R 



! # ADD UL,MODIR,3,0,R,R 



1RADEDIT 



! PAUSE KEYIN SY,S 



!JOB 



In this example, the User Library requires the following 
six files to be allocated in the User Library area (UL): 
MODIR, EBCDIC, EDFRF, BDFRF, MDFRF, and MODULE. 
The !*LADD command enters the routines into the defined 
four files, depending oh the library code parameter on the 
! # LADD command: Basic (B), Main (M), or Extended (E). 
The same basic method is used to set up the System Library. 



UTILITY EXAMPLE 

CREATE A CONTROL COMMAND FILE 



!EOD 



!EOD 



!JOB 



M 



Control command deck 




UOBC* 



! *COPY F 



!*OPLBS UO 



!*ASSIGN UO=CCFILE,UD 



!*ASSIGN UISI 



{UTILITY COPY 



! # END 



! # ADD UD, CCFILE,5,80,C,N 



IRADEDIT 



UOB 



In this example, the job stream will create the compressed 
file CCFILE in the User Data area. Control commands will 
be read from the SI device into file CCFILE. The job 
stream on CCFILE may now be executed by assigning 
CC = CCFILE, UD. Note that CCFILE must not have a 
!JOB command on its first entry, since this would imme- 
diately transfer CC back to the SYSGEN assignment. How- 
ever, it is often convenient to end the control command 
file with a UOB command to initiate a return to the 
SYSGEN assignment. 



A ! JOB command must not be the first card in the Control 
Command deck; UOBC is permissible. 
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11. SYSTEM GENERATION AND SYSTEM LOAD 



INTRODUCTION 

An RBM system designed for the requirements of a specific 
installation is generated in two phases: SYSGEN (System 
Generation) and SYS LOAD (System Load). These two phases 
create the Monitor and its required overlays. The SYSGEN 
phase defines RAD allocation or allows the user to override 
the nominal area allocation. 

SYSGEN loads only the specific installation parameters; 
none of the processors are loaded at this time. Its only out- 
put is an optional/ rebootable version of the Monitor? This 
rebootable Monitor is output on the PM (Punch Monitor) 
assigned device. 

When SYSGEN is completed, core memory is set up for the 
SYS LOAD function to load the RBM overlays. System pro- 
cessors, user processors, and other user-determined programs 
are loaded onto the RAD by the Overlay Loader or the RBM 
Absolute Loader. 

It is possible to modify the Monitor and/or its associated 
processors individually without going through the entire 
system generation process. Specifically, 

• A new version of the RBM can be written without af- 
fecting the remainder of the RAD. Therefore, reloading 
the entire RAD will not be necessary. 

• Anything on the RAD can be replaced without going 
through a SYSGEN as long as the replacements do not 
exceed their SYSGEN-defined areas. 

• One installation can perform a SYSGEN for another 
installation and merely forward a copy of the reboot- 
able RBM binary deck. However, the recipient 
facility will have to perform the SYS LOAD; that is, it 
will have to load the RBM overlays, the system proces- 
sors, the user processors, and other installation specific 
programs on the RAD. 



SYSGEN 

INITIAL CORE ALLOCATION 

The RBM system is assembled in two parts. Part 1 is assem- 
bled in absolute and contains SYSGEN (and SYSLOAD), 
and Part 2 is a stack of relocatable binary decks that may 
be loaded onto the RAD by SYSLOAD. (A list of these 
modules and their corresponding idents is given in Table 20.) 
Part 1 is loaded by an Absolute Loader (see !ABS control 
command in Chapter 2). Nonoptional resident portions of 
RBM are loaded into the low core (0K-4K) locations from 
which they will execute; optional resident routines and the 
system generation routines are loaded into high core 
(4K-12K). RBM overlays are loaded at SYSLOAD time. 
The absolute binary deck that includes all optional routines 
is initially loaded by the Absolute Loader. 



After this deck is loaded, the Absolute Loader enters the 
"wait" state. At this point the operator must enter the 
device number of the keyboard/printer into the data 
switches. (The device number used is that of the keyboard/ 
printer employed by SYSGEN to communicate with the 
operator.) Then the operator may clear the "wait", and 
SYSGEN will continue. 



MINIMUM CONFIGURATION 

The following minimum configuration is required for the 
RBM system generation: 

1. Keyboard/printer. 

2. Minimum of 16K of core storage. 

3. RAD of at least .75M bytes or disk pack. 

4. Protection and memory parity features. 

5. Hardware interrupts for the RBM Control Task and I/O. 

OPTIONAL ROUTINES 

There are two basic divisions of the optional routines: 
those actually resident at all times and those functioning 
in the overlay region. All of the routines listed in 
Table 29 function in the overlay region and therefore con- 
tribute essentially nothing to the resident size of RBM. The 
optional resident routines that contribute to the size of 

RDM _»« ~, C~ll~.w-. 





Ap 


jroximate Size 


Routine 


(decimal) 


Power On/Off 




293 


Accounting (Clock 1) 




216 


High-Speed Line Printer Handler 




62 


Magnetic Tape Handler 




95 


Multiply/Divide Simulation 




173 


M:IOEX 




198 



The presence of these optional routines is primarily depen- 
dent on the installation hardware configuration, which is 
partly determined as the device-file information is input. 
If the indicated hardware is present, SYSGEN moves the 
optional routines to the resident portion of RBM or sets the 
appropriate overlay ident into the overlay table. 
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For example, if a Y response is given for the INC. MUL/ 
DIV.SIM. query, SYSGEN moves the multiply/divide 
simulation package that is included in Part 1 to the proper 
location in core. As another example, if CR4/XX,B is 
typed under the heading DEVICE FILE INFO, SYSGEN 
enters the ident of the card reader error recovery routine 
in the OV:LOAD table. SYSLOAD encounters this ident 
while loading Part 2, singles out the corresponding module, 
and saves it as an overlay on the RAD. 



need additional core space and make the core allocation 
accordingly. A given area could then expand in a future 
SYSGEN, but only the programs in that area would have to 
be reloaded and not the entire system. (In Figure 13, for 
example, the resident foreground might expand into the 
unused Public Library area.) 



Figures 12 and 13 illustrate the core layout both after abso- 
lute load and after SYSGEN and SYSLOAD. 



Debug and the Character-Oriented Communications handler 
operate in the foreground; eithera resident foreground region 
or a nonresident foreground area must be allocated if they 
are to be included. 

A method for determining the size of RBM before a SYSGEN 
is performed is given in Appendix I. 



CORE MEMORY ALLOCATION 

Core memory is allocated in the following manner (see 
Figure 10): 

1. The first 256 words in lower memory (the zero table) 
are reserved for a communication region (see Table- 1). 

2. The region from (decimal) 256 to 399 is reserved for 
internal and external interrupt levels; any space not 
required for interrupt levels will be used by the 
Monitor for table space. 

3. The remainder of core will be allocated by SYSGEN 
as follows: 

a. Resident RBM, to be loaded beginning at location 
400 (decimal) and to include only optional routines 
selected by SYSGEN. 

b. Public Library (if allocated). 

c. Resident Foreground (if allocated). 

d. Nonresident Foreground (if allocated). 

e. Background, at least one page whether or not 
required; minimum amount allocated should be 
length of the Job Control Processor (3500 locations, 
decimal). See Figure 11. 

4. No foreground space need be allocated for a batch- 
only system. 

When all user inputs necessary to calculate the exact size 
of the resident RBM are made, the ending address of 
RBM will be output by SYSGEN. The user will then input 
starting addresses for the Public Library, the resident fore- 
ground, the nonresident foreground, and the background. 
The user should decide which of these areas are more apt to 



RAD ALLOCATION 

During SYSGEN, each RAD or disk pack that will be 
mounted during SYSLOAD may be divided into from 1 to 
16 areas. Each area is labeled with an area mnemonic, 
usually from the following list: 



Xn 



SP 


FP 


SD 


BP 


SL 


UP 


BT 


UL 


CP 


aa 



where aa is any remaining combination of alphanumeric 
characters, except Xn. 

Areas are allocated by tracks, so that the actual size of an 
area is dependent on the type of RAD device. The track 
sizes are 



Track Size 
2880 words/track 
6144 words/track 
3072 words/track 



Models 

7202, 7203, 7204 

7232 

7242, 7246 



If the first area allocated to each RAD is not preceded by an 
SK (skip track) input, the system bootstrap wi 1 1 be written 
in sector 0, and the area wilt actually begin at sector 1. 
All other areas, with the possible exception of the BT area, 
will always start on a track boundary. The five areas 
described below may receive default allocations. During 
RAD allocation, the user must specify a system RAD to 
receive the default areas. An SK input as the last input on 
the system RAD will be ignored if default allocations are 
to be made. 

The SP, SD, SL, BT, and CP areas may receive default speci- 
fications. During SYSGEN, the user must specify a default 
RAD to receive all of the areas specified by default. Any 
default area except SD or SP may be eliminated by specify- 
ing its size as zero. A default area (if explicitly specified) 
may be placed on a RAD other than the default RAD. 

The areas that may be default allocated and their sizes are: 

SP Only large enough to contain RBM and its over- 
lays and all standard processors (see Table H-2). 
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(KrPLFWA) 

(KrRFFWA) 

c 

u 

L 

t- 

c 

, C 

c 

(KrNFFWA) 

(KrBACKP) 
(KrBACKBG) 

c 

u 

U 

h 

c 

a 

c 

(KtUNAVBG) ' 




Low Core 




3 

j 

5 

L. 


External/Internal Dedicated Interrupt Locations 
Zero Table: Constants and Pointers 


RBM 


Resident RBM 


Selectable, optional RBM Routines 


I/O tables for RBM 


Transfer Vector Table 


Public Library 




Real-time task "i temp stack 


Resident 

Foreground Program *1 


Task Control Block #1 


Real-time task *1 


Real-time task *2 temp stack 


Task Control Block # 2 


Real-time task # 2 


Special end-action I/O routine 


Foreground program *1 COMMON 


• 


Additional Resident 
Foreground 


Real-time task *N temp stack 


Nonresident 
Foreground Space 


Task Control Block # N 


Real-time task ^N 


Background TCB 




J 

) 

J 

L. 

5 

f 


Background temp stack 


Background Program 


User main program 


User subprograms 


Library subprograms 


Blank COMMON (if any) 




High Core 





Figure 10. RBM Core Memory Allocation Example 
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Low Core 



High Core 



Background TCB, without PSD 
(In protected memory) 



Floating accumulator (5 locations) 



FORTRAN I/O Format Information 



Allocated temporary space 



Unallocated (as yet) temporary 
space for Public Library and 
Monitor Service Routines use. 



User Program and subprograms 
(Including any library routines 
not in the Public Library) 



Unused core 



RAD I/O Blocking Buffers 
(From 1 to 16 buffers; size of 
buffer determined at SYSGEN) 



Blank COMMON (if any) 



(Unavailable Memory) 



(KrBACKP) 



(K:BACKBG),(K:BASE) 



TEMPBASE+6 



K:DYN 



TEMPLIM 



(KrBACKBUF) 



(KrUNAVBG) 



Figure 11. Background Core Allocation Example 
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RBM Zero Table 




RBM Resident Routines 


RBM Optional Resident Routines 
and Tables 


RBM SYSGEN 


RBM SYSLOAD 


RBM Optional Nonresident 
Routines 


TVECT Table 









Figure 12. Core Layout After Absolute Load 



RBM Zero Table 



Interrupt Locations (Unused Interrupt 
Locations Used by RBM Tables) 



RBM Resident Portion 
(Nonoptional Routines) 



RBM Overlay Region (512 Words) 



RBM Resident Region (Optional 
Routines) 



RBM Patch Area 



Transfer Vector Table for 
RBM and Public Library 



Public Library 



Unused Public Library Area 



Resident Foreground 



Unused Resident Foreground Area 



Nonresident Foreground 



Unused Nonresident Foreground Area 



Background (RBM Overlay Area for 
JCP) 





TOO 

190 



High Core 



SD Only large enough to contain nominally large 
RBMGO and RBMOV files, and other small files 
(RBMS2 # RBMID, etc.). 

SL Only large enough to contain the standard system 
libraries: Standard precision, extended precision 
and common, or main libraries. 

CP Only large enough to contain all of background. 

BT Remaining RAD space. The last track available 
for the default assignment of this area is device 
specific as follows: 



Device 

7202 
7203 

7204, 7232 
7242, 7246 



Last track available + 1 

128 
256 
512 
4000 



Each area will have a protection code assigned to it. This 
protection code is checked by the RAD Editor. The pro- 
tection codes are: 



Protection 
Code 

NO 

BG 

FG 
SY 



Meaning 

No restriction 

Background files and files without write 
protection may be added, deleted, etc. , 
with no restriction. 

Foreground and unprotected files may be 
added if an SY key-in is in effect. 

Any of the files may be added if an 
SY key-in is in effect. 



The following areas have unconditionally specified protec- 
tion codes: 



Area 



Protection Code 



Figure 13. Core Layout After SYSGEN and SYSLOAD 



SP, SL, SD SY 
FP, CP FG 

BP, BT BG 

The other areas may have an area protection code assigned 
during SYSGEN. If none is specified, the default is SY. 

RAD allocation is performed by making a device specifica- 
tion, and following it by a set of area specifications for that 
device. This procedure is followed for each device and RAD 
allocation is terminated by an END statement. 

RAD allocation at SYSGEN constructs the Master Directory, 
consisting of four words per entry. The only restrictions are 
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that each area mnemonic must be alphanumeric, the size of 
the Master Directory may not be exceeded and RBM cannot 
cross a cylinder boundary. Any area except SP may be re- 
moved from the Master Directory by setting its size to zero. 
Areas SP, SD, SL, BT, and CP, are initially placed in the 
Master Directory in that order, if space is available. Any 
of these areas not desired should be removed at the begin- 
ning of RAD allocation to provide room for the areas to be 
allocated. If the area is to be deleted, an area allocation 
does not have to follow a device specification. 



FILE CONTROL TABLE ALLOCATION 

The File Control Table (FCT) is indexed by device-file 
number and contains information about all device-files in 
the system. The total size of the File Control Table is 
determined and allocated at SYS GEN time. The. term 
device file number (DFN) is assigned on the basis of the 
order in which devicesare defined. For example, since the 
first device defined must a I ways be a keyboard printer, DFN 1 
will always specify a keyboard printer. Devices other than 
the RAD have permanent device-file number assignments 
made at SYSGEN time. SYSGEN allows room for up to 
50 permanent device-files (not including RAD files). 

A separate device-file (i.e., FCT entry) is required for 
each open file on the RAD. Hence, the total number of 
entries necessary in the File Control Table for all RAD files 
is the maximum number of simultaneous open files. At 
SYSGEN time, the user must specify this maximum number 
of device-files for his foreground programs. For the back- 
ground, nine device-files will be allocated (a sufficient 
number for the system processors), plus the number of RAD 
background DFNs input by the user. 



SYSGEN always allocates three foreground RAD files for 
use by the Monitor in addition to the number of RAD fore- 
ground files input by the user. Hence, the total size of the 
File Control Table will be the sum of the number of non- 
RAD files assigned, plus the total number of RAD files re- 
served for foreground use plus three, plus the number of 
RAD files reserved for background use plus nine. 

The user can make file dictionary entries on the RAD for 
his foreground programs and then permanently allocate a 
foreground device-file number to that RAD file by assigning 
the RAD file to a foreground operational label. A device- 
file number reserved for background use is assigned by the 
Monitor service routines M:DEFINE and M:ASSIGN when- 
ever a call is made to either of these routines. For RAD 
device-files, SYSGEN allocates the appropriate space in 
the File Control Table and sets the background/foreground 
indicator, the "file for RAD use" indicator, the maximum 
retry counter, and the pointer to the I/O Control Table. 
For non-RAD files, SYSGEN sets in the File Control Table 
the background/foreground indicator, the channel number, 
the device type number, the "file for non-RAD use" indi- 
cator, the device number, the maximum retry counter, and 
the pointer to the I/O Control Table. 



SYSGEN also allocates space for the I/O Control Table. 
The amount of space required for each type of device is 
contained in the Device Type Table. 



OPERATIONAL LABEL ASSIGNMENTS 

During SYSGEN the user specifies the selected standard 
operational labels and assigns each to a device-file num- 
ber (other than a RAD file number) or to device-file zero. 
These assignments will be maintained as permanent assign- 
ments for the appropriate operational label. 



The operational labels listed below are normally associated 
with RAD files. Therefore, permanently assigning these 
labels to non-RAD files at SYSGEN time is not permitted. 



Operational 
Label 

RM 



ML 



PI 



OV 



XI -X5 



S2 



GO 



CK 



Use 

Used by RBM to load the RBM overlays and 
is reserved exclusively for RBM. 

Used by M:LOAD to load nonresident fore- 
ground programs. 

Should be used by any background program 
with overlays to load the overlay segments 
from the RAD. For system processors, PI is 
assigned to the processor file. For back- 
ground programs loaded with an XEQ com- 
mand, PI is assigned to OV. Foreground 
programs must specifically assign an opera- 
tional label to the file from which overlay 
segments are to be read. 

Normally assigned to the RBMOV file for 
"assemble and go" type operations. 

Processor scratch files. 

XSYMBOL standard procedures. 

Normally assigned to the RBMGO file for 
"assemble and go" type operations. 

Used to write/read checkpoint area. 



After all inputs are made by the user, SYSGEN allocates 
three additional entries in the Foreground Operation Label 
Table for RAD foreground labels. 

A total of 100 operational labels can be allocated and as- 
signed at SYSGEN time, including those automatically 
allocated by SYSGEN. 

INPUT PARAMETERS 

When RBM is loaded and control is transferred to the 
SYSGEN routine, operator intervention is required to input 
the system parameters. The following device types are 
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standard must be referred to by name when inputting the 
device-file definitions: 



SYSGEN 
Device 
Type Name 

KP 

M9 

PT 

M7 

B7 

RD* 
XX 

LP2 
LP8 
CR4 

BR4 



Device Characteristics 

Keyboard/printer 

Magnetic tape, 9-track 

Paper tape handler 

Magnetic tape, 7-track, 
packed binary option 

Magnetic tape, 7-track 
BCD option 

RAD or disk pack 

Special -purpose device for 
use with M:IOEX 

Line printer, 240 Ipm 

Line printer, 800 Ipm 

Card reader, EBCDIC option, 
1400 or 400 cpm 

Card reader, BCD option, 
1400 or 400 cpm 



Run- 
Time 
Device 
Name 

KP 

M9 

PT 

M7 

MB 
RD 

LP 
LP 
CR 

CR 



SYSGEN 
Device 
Type Name 

CP3 

BP3 

CPl 

BP1 
PL 







Run- 






Time 






Device 


Device Characterisitcs 


Name 


Card punch, 


200 cpm 


CP 


Card punch, 


BCD option, 


CP 


200 cpm 






Card punch, 


EBCDIC option, 


CP 


100 cpm 






Card punch, 


100 cpm 
. tt 


CP 



Graphic plotter 



The Run-Time names are used by M:READ/M: WRITE for 
operator communication. 

Table 27 defines the system parameters that are input via the 
keyboard/printer, paper tape reader, or card reader during 
SYSGEN. Note that all numeric entries can be input in 
either decimal or hexadecimal with leading zeros ignored; 
all hexadecimal entries must be preceded by a +. Comments 
can be added to any of the inputs shown in Table 27 by 
leaving one space after the required input is made. All in- 
puts from the keyboard/printer must terminate with a NEW 
LINE code. Commas are used to separate fields. If an 
input/output device is not in the START state, an appropri- 
ate message will be written on the keyboard/printer. 



tt 



RD is used only to reserve a specific number of foreground 
or background RAD files, not as a name of the form dtnn. 



RBM supports the graphic plotter as a device type but will 
not do any special converting or formatting. The user can 
either use the existing library routines to format data for the 
plotter or perform his own formatting. 



Table 27. SYSGEN Input Options and Parameters 



Output Message 


Input Parameters 


Description 


!!RBM SYSGEN 
INPUT DEVICES 


Device Name and Number 
(e.g., CR4/03,LP8/02;KP, 
NO;PT20,KP) 


Device name and device number of the input and output 
devices to be used during SYSGEN. If the keyboard/ 
printer is to be used exclusively, only KP need be input. 
The only acceptable device names are CR, LP, KP, PT, 
or NO. 

If DATA switch 1 is set at the time the input device 
parameter is input, patch commdnds are read from the 
input device until an !EOD is encountered. See PA 
option under "SYSLOAD". 


VERSION 


Two alphanumeric characters 
(e.g., Al or A2 or Bl, etc) 


The RBM version will be stored in a zero table 
location. K:VRSION, output by RBM on LL at the 
start of each job and by postmortem dump whenever 
it runs. 
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Table 27. SYSGEN Input Options and Parameters (cont. ) 



Output Message 


Input Parameters 


Description 


MEMORY SIZE 


Numeric size 


Total core memory size of Sigma 2/3, stored in a zero 
table location, K.-UNAVBG. 


MAX. INT. LOC 


Address 


Maximum Sigma 2/3 address for real-time external 
interrupts (263 < A <400). The space unused by the 
interrupts will be allocated to RBM tables by SYSGEN. 


CONTROL TASK INT. LOC. 


Address 


Address of interrupt used by RBM Control Task. Must 
be the interrupt with the lowest priority available. 


INT. CHANNELS 
EXT. CHANNELS 


x - y or 


Indicates the numbers of the I/O channels specified to 
this installation, x is the first channel number, and y 
is the last number. If no channel exists for this IOP, 
a is input. Sigma 2, for example, would always have 
an input of for EXT. CHANNELS. The number of 
channels must be greater than four but less than 20 for 
Sigma 2 (less than 28 for Sigma 3). For Sigma 3, 
through X'B 1 are the internal channel numbers and 
X'C through X'lB 1 are the external channel numbers. 


NO. LINES/PAGE 


Number 


Number of lines to be printed on each page during an 
Extended Symbol assembly. SYSGEN will save the 
input value in zero table location KrPAGE, for later 
use by Extended Symbol in printing out a title at the 
top of each page. Input value n must beO < n < + 8000. 


NO. DEFS IN PUB. LIB. 


Number 


Number (n < + 100) of definitions (DEFs) in the Public 
Library. This input is needed so that the Transfer Vector 
Table can be correctly allocated. If zero is input, 
SYSGEN assumes there is no Public Library. 


NO. ENTRIES IN 
NONRES. FGD. QUEUE 


Number 


Reflects the maximum queue size for nonresident fore- 
ground programs. 


NO. DICT ENTRIES 


Number 


Specifies the length of the Master Dictionary. Entries 
are already allocated for SP, SD, SL, CP, and BT. A 
number from to 15 may be input, specifying the addi- 
tional Master Directory entries. Each entry requires 
four words. 


RAD ALLOCATION 


RDxx/dn fjpks 

For example, 
RD42/E1,S 


xx specifies the device type as follows: 

02 7202 

03 7203 

04 7204 
32 7232 
42 7242 

dn is the hardware device number for this RAD, which 
must be driven by a channel defined previously under 
"INT CHANNEL" or "EXT CHANNELS". Each device 
can only be input once, but as many as 12 devices, 
each with area allocations, may be input. I or E spec- 
ifies the IOP type; I refers to an Internal IOP, and Eto 
an External IOP. E is assumed for a 7242 or 7246 and 



SYSGEN 



129 



Table 27. SYSGEN Input Options and Parameters (cont. ) 



Output Message 


Input Parameters 


Description 


RAD ALLOCATION (cont. ) 




is the default for a 7232. I or E must be input for a 
720x. If this parameter is not used, an intervening 
comma before the next parameter is not necessary. 

S indicates that this device is to receive default allo- 
cations. If more than one S parameter is input the last 
is used. If S is not input, the device receiving the 
SP area is used. Either S or the SP area must be input. 


yy = zz [, wp] 


yy is any area mnemonic, usually from the following 
list: 




For example: 






SP FP Xn 




SP = 30 


SD BP 




SD = 20 


SL UP 




Dl = 100, FG 


BT UL 




D2 = 200, BG 


CP era 
where a is any letter except X and n is a decimal digit. 

zz is the number of tracks to allocate for area yy. If 
zz = 0, area yy will be undefined, and an additional 
Master Directory entry will be available. If zz = 
ALL, the area will occupy the remainder of the RAD 
and no other inputs may be made for this RAD. If 
yy = SK, zz number of tracks will be skipped before the 
next area is allocated. But to be meaningful, another 
area must be input. If the first input is not SK = zz, 
this RAD will receive a system bootstrap in sector and 
the next area will actually begin in sector 1. If no 
orders are allocated on RAD dn, however, no bootstrap 
will be written. 

wp is a write protection code from the set NO, SY, 
FG, or BG. This option is not valid for the SP, SD, 
SL, BT, CP, FP, or BP areas. For all other areas, the 
default is SY. 


END 


Terminates the RAD ALLOCATION parameter. 






In the example given, areas SP, SD, Dl and D2 will 






receive the number of tracks specified. SL, CP, and 






BT will be default allocated, (as described under RAD 






ALLOCATION) on this same device. 


BUFFER SIZE 


0, 180,or512 


Specifies the blocking buffer size for all Monitor blocked 
files in this system. If is input, the largest sector 
size of the SYSGEN configuration is used. 


INC. POWER ON/OFF 


YorN 


Yes (Y), if Power On/Power Off routine is to be in- 
cluded in resident RBM. 


INC. MUl/DIV. SIM. 


Yor N 


Yes (Y), if multiply/divide software is to be included. 
If multiply/divide hardware exists, No (N) should be 
input. 


iKir A/i.incY 


V „- M 








be included. 
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Table 27. SYSGEN Input Options and Parameters (cont. ) 



Output Message 



Input Parameters 



Description 



INC. CLOCK ONE 



Yor N 



Yes (Y), if Clock 1 is to be used by RBM for job 
accounting, for limiting the execution time of back- 
ground fobs, for time limits on I/O transfers, and for 
keeping time of day. If NO (N) is input, Clock 1 is 
not available and SYSGEN will not load the job ac- 
counting portion of the RBM Control Task. 



INC DEBUG 



Yor N 



Yes (Y), if RBM Debug is to be included. If Debug is 
included, at least 200n Q \ foreground cells must be 
allocated and Debug I/O device may be input below, 
under DEVICE FILE INFO. If No (N) is input, Debug 
will not be loaded and the user can use the 32 zero 
table Debug cells as additional foreground mailboxes. 



INC. MISC. 



Yor N 



Yes (Y), if the non-Debug Core Dump, RAD Dump, 
and Hex Corrector routines are to be included in RBM. 



INC. C.O.C. 



Yor N 



Yes (Y), if Character-Oriented Communications 
Handler is to be included. If COC is included, at 
least 1000 cells must be allocated for resident 
foreground. 



INC ERR. LOG 



Yor N 



Yes (Y) if RBM is to attempt to write a message when a 
system crash is to occur. The resident size will increase 
by 25 cells. 



DEVICE FILE INFO. 
[(INC. DEBUG)] 



dtnn,x , 



§ 



RD,x,y 



The first parameter, dt, specifies a certain peripheral 
and must be one of the device type names listed pre- 
viously under "Input Parameters". The second param- 
eter, nn, is the hardware device number of this pe- 
ripheral and must indicate a previously defined 
channel. The third parameter, x, is F if this is a 
foreground device, B if this is a background device, 
DI if this is a Debug input device, or DO if this is a 
Debug output device. (DI and DO will not be accepted 
if an N (no) response was given to the INC. DEBUG 
message. ) The last parameter, I or E, is required to 
indicate IOP type for a multiunit device; I indicates 
an internal IOP, and E indicates an external IOP. The 
last parameter is ignored if the device is not a multi- 
unit type. 

The first device-file entry, DFN 1, must be KPnn, F. 
the term "device-file number", abbreviated as DFN, 
indicates the order in which device parameters are in- 
put in response to the DEVICE FILE INFO, output 
message. 



This entry indicates to SYSGEN that y RAD File Con- 
trol Table entries are to be saved for the mode specified 
by the parameter x where y is F for foreground files or 
B for background files. The y parameter may be one or 
two decimal digits. An entry must always be input for 
the foreground, and a default number of 9 is used for 
background files if a user fails to allocate any back- 
ground file. (Thus if no input is given, SYSGEN will 
reserve nine background RAD file entries. ) The value 9 
is always added to the background allocation. 
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Table 27. SYSGEN Input Options and Parameters (cont. ) 



Output Message 


Input Parameters 


Description 


DEVICE FILE INFO. 


RD, x,y (cont.) 


Examples: 


(INC. DEBUG) (cont.) 




Device-File DFN No. 

KP40, F 1 
LP8/02, B 2 
CR4/03, B 3 
CPl/04, B 4 
PT20, B 5 
BR4/03, B 6 
M9D0, B, E 7 
M9D1,B, E 8 
uvm n f o 

B7E0,B,E 10 
RD, B, 20 28-46 
LP2/05, F 1 1 
CR4/03,F 12 
M9D0, F, E 13 
M9D1,F, E 14 
XXDO, F 15 
LP8/02,D0 16 
CR4/03,D1 17 
RD,F, 10 18-27 

Note: RAD files are entered last regardless of 
sequence placement and foreground files 
will have the lower DFN assignment. 


END 


Signifies end of device-file information. 


BCKG. OP. LBL. 


Operational label = device- 


Background operational labels or device-unit number 




file number, or device unit 


and device-file number equivalents for permanent I/O 




number = device-file number 


assignments. No operational labels can be assigned to 




(one per line, terminated by 


RAD files at SYSGEN time. A maximum of 188 back- 




END); = n means reserve n 


ground and foreground operational labels can be input 




locations in Operational 


by the user. The following operational labels are de- 




Label Table for temporary 


fined by RBM; thus, they may not be input: 




assignments. (Temporary 






space is needed for execution 


RM OV 




time temporary assignments, 


ML GO 




or for RAD files above and 


PI 




beyond that number (9) which 






is automatically allocated by 






SYSGEN.) 






Examples: 






SI = 3 






102=4 






= 3 (reserves three addi- 






tional entries in Op- 






erational Label Table) 




END 


Signifies end of background operational label. 


FGD. OP. LBL. 


Same as for background, 


Foreground operational iabeis or device unit number and 




except that space for three 


device-file number equivalents for permanent foreground 
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Table 27. SYS GEN Input Options and Parameters (cont. ) 



Output Message 


Input Parameters 


Description 


FGD. OP. LBL. (cont.) 


operational labels are 
automatically assigned. 


I/O assignments. No foreground operational labels 
can be assigned to RAD files at SYSGEN time. 


RBM LWA = + xxxx 


None 


At this point, SYSGEN will have sufficient information 
to calculate the exact size of RBM. This message is 
output to the operator as an aid in the follow-on inputs. 
If the user has only background, he will have to input 
an address for the start of the background (i.e., at 
least 17 cells greater than the RBM LWA output). This 
value (i.e., + xxxx) can be predetermined by using 
the algorithm given in Appendix I. Any excess space 
will be used as the RBM Patch area. 


PUB. LIB. FWA tt 


Address 


If zero has been input for the number of DEFs in the 
Public Library, this typeout will not occur. Otherwise, 
the input should reflect the first word address (FWA) of 
the Public Library (which may be equal to RBM LWA). 
An input of zero is illegal. This value is stored in zero 
table location KrPLFWA. 


RES. FGD. FWA tf 


Address 


First word address of the resident foreground area. An 
input of zero indicates no resident foreground. This 
value is stored in zero table K:RFFWA. 


NONRES. FGD. FWA tf 


Address 


First word address of nonresident foreground area. An 
input of zero indicates no nonresident foreground. This 
value is stored in zero table location K:NFFWA. 


BCKG. FWA tf 


Address 


First word address (FWA) of background memory. This 
address must start on a page boundary (some multiple of 
lOOj^). This value is stored in zero table location 
KrBACKBG. 


Although Sigma 3 has provisions for interrupt locations only as high as 368, 400 is considered to be the beginning of 
operating RBM for compatibility with Sigma 2. The 32 extra cells are used for input/output tables. 

These four addresses must be in increasing order. That is, the core allocation must be made in the same order as the 
SYSGEN input. If nonresident foreground is used, it must be at least 17 cells plus the sector size of the UP area. This 
area is used as a buffer for the Q key-in. 



SYSGEN OUTPUT 



SYSLOAD 



MESSAGES TO THE OPERATOR 



SYSTEM LOAD 



The error messages in Table 28 can be output by SYSGEN. 
Note that for input errors the corrected input must be made 
from the KP exclusively. 



BINARY OUTPUT 



After SYSGEN has been completed, or the rebootable RBM 
deck punched by SYSGEN has been input, control is trans- 
ferred to the System Load Processor, SYSLOAD. SYSLOAD 
will initially output the following message on the OC 
device: 



If a background PM (Punch Monitor) operational label is 
assigned at SYSGEN time, SYSGEN will punch a reboot- 
able version of the RBM on the PM device after the last 
parameter has been input by the operator. 



NRBM SYSLOAD 
HINPUT OPTION 
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Table 28. SYS GEN Error Messages 



Message 


Meaning 


Recovery 


!! INVALID PARAMETER 


Input parameter is out of 
expected range, or maximum 
number of allowed inputs 
have been made. 


Retype input with correct value. 


! ! FORMAT ERR 


Input format not valid. 


Retype input with valid format. 


!!C. LINT. PRIORITY ERR 


Control task interrupt is at 
a higher priority level than 
the I/O interrupt level. 


Requires hardware modification, or reassignment of 
Control Task Interrupt to a lower level. 


iil/O ERR 


An I/O error has occurred 
on the last input. 


Correct the problem with the input device and 
retype last in n ut. 


!! ALLOCATION ERR 


No RAD was defined as the 
system RAD. 


Since this alarm is output only after the END card 
is input (i.e., after the RAD allocation has been 
completed), the user must reallocate all areas 
assigned to the system RAD. The default allocations 
will be restored for the second iteration. The com- 
puter will enter a "wait" state so that the error can 
be isolated and corrected unlike other SYSGEN 
errors. The corrected inputs must be made on the 
original input device. 


TOO MANY AREAS 


Not enough entries were 
defined in the Master 
Dictionary. 


Fewer entries must be input or more Master Dic- 
tionary entries must be made available. In any 
event, RAD allocation must be restored. 


RBM CAN'T BOOT 


RBM resides on a 7242 disk 
and crosses a cylinder 
boundary. 


SP must be reallocated during a second RAD 
allocation. 


!! ILLEGAL OP. LBL. 


The user has attempted to 
permanently assign one of 
the reserved op labels (RM, 
ML, PI, OV, GO). 


Retype input with different op label. 



The option to be input on OC should be one of the following: 

PA specifies that patches are to read from the input 

device, with the format xxxxfcfcyyyy^ozzzz]. . . 
!EOD where xxxx is the location to be patched, 
and yyyy and zzzz are the values to be inserted 
starting at location xxxx. All entries must be four 
characters long, separated by two blanks. The last 
record must be !EOD to terminate patching and 
causes the ! ! INPUT OPTION message to be out- 
put again. The ALL or UPD option can then be 
entered. Comments may be made in two ways on 
SYSLOAD patch cards. If the first column contains 
an asterisk, the entire card will be considered a 
comment card; otherwise comments may be made on 
cards containing patches by preceding the com- 
ments with an asterisk. 

ALL which specifies that a complete system load 

is to occur and nothing on the RAD is to be 
saved. 



UPD which specifies that an updated version of RBM 

has been made to replace the existing RAD version. 
Portions of the RAD may have to be reloaded, de- 
pending on the new core memory allocation. 

ALL OPTION 

An ALL input specifies that a complete system load is to 
occur. A complete load is necessary for the initial genera- 
tion or whenever any of the RAD areas has to change size. 

The System Load Processor SYSLOAD first searches the 
Master Directory left by SYSGEN to determine if any RAD 
areas have not been completely defined because of an ALL 
input during SYSGEN. If some areas still need their last 
word addresses defined, SYSLOAD will generate this value 
so that the Master Directory can now be completed. 

At this point a check is made to determine if the 
checkpoint area is large enough to contain the entire 
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background- If it is not, the following message will be 
output: 



If any of the following modules are relocated on the RAD, 
the contents of other affected areas must be reloaded: 



CP AREA TOO SMALL 



The CP area will be undefined. 

This error is only fatal if an attempt is made to checkpoint 
the background. It can be corrected only by a complete 
SYSGEN, using at least the default size for the check- 
point area. 

After the Master Directory has been completed, SYSLOAD 
will write zeros on all defined areas of the RAD. This pro- 
cess takes approximately 1 minute for a 256-track RAD. 

UPD OPTION (UPDATE) 

The UPD option on the SYSLOAD command specifies that a 
new version of RBM has been made, but that none of the 
areas on the RAD has changed in size. The option can 
also be used when changes are made in any of the following 
input parameters: 

• Public Library (PL) FWA 

• Resident Foreground FWA 

• Nonresident Foreground FWA 

• Background FWA 

UPD should not be used if any of the RAD areas has changed 
in size or location. In this case, a complete SYSGEN 
and SYSLOAD must be performed. Note that a change in 
the background FWA to increase the total size of background 
might cause a change in size of the Checkpoint area, which 
could necessitate a complete new SYSGEN. In this case, 
a CP AREA TOO SMALL alarm would be output for the 
user's information. 

The System Load Processor reads the bootstrap to determine 
where the old version of the RBM is located on the RAD and 
then loads the Monitor Constant Table. The SYSLOAD then 
compares the old load addresses against the new load ad- 
dresses to determine which programs on the RAD must be 
reloaded. 

The size of the new Master Directory must be at least as 
large as the old Master Directory. If it is not, an error 
message will be output and SYSLOAD will continue. 

If the new version of RBM exceeds the RAD space allocated 
to the old version, all programs in the System Processor area 
and all programs that make external references to Monitor 
service routines (MSR) must be reloaded. (Reloading the 
System Processor area is necessary because the RBM is the 
first file in the area.) As the comparison checks are made, 
a subset of the following messages will be typed on OC: 

! [RELOAD 
PUB. LIB. 
RES. FGD. 
NONRES. FGD. 
BCKG. 
SP AREA 

MSR/PL USERS AND PL 
NOTHING 



Relocated Module 



Required Reloading 



Public Library requires All programs that reference the 
reloading because its Public Library must also be re- 
load address has loaded. None of the system pro- 
changed, cessors use the Public Library, and 

no system processors would have 

to be reloaded. 



Resident or nonresi- 
dent foreground was 
relocated. 

Background was 
relocated. 



New RBM version ex- 
ceeds its allocated 
RAD file space. 



TVECT Table load 
address has changed. 



The appropriate routines must be 
reloaded in these areas. 



All system processor and back- 
ground user programs must be 
reloaded. (See "Initial Loading 
of System Processors" below. ) 

All programs in the system pro- 
cessor area must be reloaded. 
(See "Initial Loading of System 
Processors" below. )' 

All programs referencing Monitor 
service routines (MSR) or the 
Public Library (PL) through the 
TVECT Table via an external 
reference must be relocated. 



After these checks are made, the SYS LOAD outputs the message 



! ! LOAD RBM PART 2 



and proceeds to load the overlays as described earlier in 
the "ALL Option". 

After the overlays are loaded, another check is made to see 
if the overlays did not overflow RBM. If the overlays did 
overflow into the next area, the following message is output: 



!! RE LOAD 
SP AREA 



After the necessary RELOAD alarms are output for the user's 
information, the SLPwill load the Master Directory from 
the RAD version of RBM and store it into its allocated area 
in the new version of RBM. The new version of RBM will 
then be written onto the RBM file, followed by an updated 
bootstrap in the BOOT file, the starting sector of the system 
RAD, and the PM device. Finally, the Transfer Vector 
Table and the RBM Symbol Table will be updated and then 
rewritten on the RAD. 



The only areas of the RAD that would never have to be 
reloaded are the system and user library areas since these 
areas contain library programs in relocatable binary format. 



tt 



The TVECT load address will change any time the first word 
address of the area adjacent to RBM in core has changed. 
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LOADING RBM PART 2 

At this point the SYSLOAD outputs the following message. 



Table 29. Routines and Idents for RBM Part 2 (cont. ) 



! ! LOAD RBM PART 2 



If SYSLOAD encounters a track upon which it cannot write, 
an appropriate message will be output with that track 
number. 

SYSLOAD will write into the first sector of each area: the 
area mnemonic and the bounds of the area. SYSLOAD will 
also clear the second sector of each area. 

The binary modules making up Part 2 should be input from the 
background AI device (as determined at SYS GEN). 

So that a user does not have to reorganize Part 2 for each 
new SYSGEN, SYSLOAD allows all or Part 2 to be input 
each time, but only loads the routines specified by the 
options selected during SYSGEN. The final module must 
be followed by an !EOD. The ident from the Extended 
Symbol directive, IDNT, is used to identify each module 
loaded, and is placed in the OV:LOAD table and used as 
the overlay identification. 

The routines making up RBM Part 2 and their idents are 
listed in Table 29. 



Table 29. Routines and Idents for RBM Part 2 







Ident 


Group 


Overlay 


(hexadecimal) 


Monitor 


MrASSIGN 


Al 


Servi ce 


M:DEFINE 


A2 


Routines 


M:OPEN 


A3 




MrCLOSE 


A4 




M:LOAD 


A5 




M:DOW 


A6 




M:WAIT 


A7 




M:CTRL 


A8 




M:RSVP 


A9 




MrDATIME 


AA 




M:COC 


AB 




RAD Bootstrap 


AC 




QrMESS 


12 


Control Task 


SrCKPT 


1 


Subtasks 


S:REST 


2 




S.-LOAD 


3 




S:ABORT 


4 




SrTERM 


5 




S:KEY 


7 




S.-KEY2 


72 




S:KEY3 


73 




S:KEY4 


74 




S:PMD 


8 




S:PMD1 


si 




S:CCI 


B 




S:PARPWR 


FF 



Group 


Overlay 


Ident 
(hexadecimal) 


Background 


BACKCCI 


10 


Debug 


All Overlays 


20-2F 


Device- 
Dependent 
Error Recovery 
Routines 


All 


30-3F 


Miscellaneous 
Routines 


Core Dump and 

RAD Dump 
Hex v^orrector 
File Dump 


40 

A 1 
H 1 

42 



SYSLOAD loads the required overlays, absolutizes them for 
their execution location, and writes each overlay on the 
RAD in an unpacked format. Only one overlay can occupy 
the overlay area in memory at any one time. SYSLOAD 
stores the RAD address (as a displacement) and the word 
count of each overlay in the RBM OVrLOAD table. The 
OVrLOAD table has the following format: 



OVrLOAD 


Number of entries 






FWA 


Ident 


-i 


First 






Word size 


entry 



15 



Consecutive entries 



where FWA is the starting sector number (relative to the be- 
ginning of the system processor area) of this overlay. All 
overlays start on a sector boundary. No overlays cross a 
track boundary. 

If an error condition occurs during the loading of the indi- 
vidual modules making up RBM Part 2, the following mes- 
sage is output: 



XX ERR, ID:YY 
??RETRY? 



where 






XX 


is one 


of the following error types 




XX 


Error Type 




CS 


Checksum 




so 


Sequence 




TY 


Item type; no external 



definitions are allowed 
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XX Error Type 

BI Binary deck is incomplete 

OG Origin error; an attempt has been 
made to re-origin a portion of this 
routine to a region already on the 
RAD 

LG Length; the specified overlay is 

longer than the overlay regions. 

YY is the ident of the current routine (if the ident 
is unknown, YY = ??). 

The response to the RETRY query can be either N (no) or 
Y (yes). If the response is N, the SLP skips to the next 
routine. If Y is input, the current routine is left as is and 
an attempt is made to continue with the next card; for some 
of the above errors, however, continuing in this manner 
may be undesirable. 

After loading all of RBM Part 2, SYSLOAD determines if 
all required routines are present. If some routines are 
missing, the following alarm is typed: 



! ! MISSING IDENTS: xx xx xx xx 
??RELOAD? 



where xx is the ident (Extended Symbol directive IDNT) 
corresponding to the missing routine. 

If Y is input to the reload query, SYSLOAD again reads the 
AI device to load the missing routines. This sequence is 
repeated until all required routines are loaded or until an 
N is input. 

After RBM Part 2 has been loaded, entries will then be 
made in the System Processor Dictionary for RBM, the Trans- 
fer Vector Table, and the RBM bootstrap. Each of these 
items is assigned in a separate file in the system processor 
area of the RAD. 

After the nonresident portion of the RBM is on the RAD, the 
resident portion is written. SYSLOAD calculates the IOCDs 
needed to read RBM into core storage and stores the infor- 
mation into the last part of the RAD bootstrap. 

After RBM is written on the RAD, the Transfer Vector Table 
will be written onto the TVECT file. The Transfer Vector 
Table contains transfer vectors for Monitor service routines 
and Public Library routines. The amount of RAD space allo- 
cated for the TVECT file depends on the maximum number 
of DEFs in the Public Library, which is a SYSGEN input. 

The final program output to the System Processor area of 
the RAD will be a copy of the RBM bootstrap that goes into 
the BOOT file. There is no file header for the bootstrap, 
and the bootstrap is always restricted to one sector. It is 
necessary to define the bootstrap as a file, so that it can 
be accessed for output during a RAD save or dump opera- 
tion. After the bootstrap is written onto the BOOT file, it 



is written onto relative sector zero of the system RAD, from 
where -it can be bootstrapped into core. Also, a copy of 
the RAD bootstrap may be output to the foreground BO de- 
vice, which enables the user to start RBM on any sector of 
the RAD or to boot from a disk pack. If the user chooses 
to start RBM at any sector other than sector zero, he can 
still reboot RBM by loading the RAD bootstrap that was 
punched on the BO device. 

The next output to the RAD will be the RBM Symbol Table 
(a file in the System Data area) and the System Data Area 
Dictionary. The System Data Area Dictionary has the same 
format as the System Processor Dictionary and contains the 
following files: 

File Name Description 

RBMGO Object module storage for "assemble and 

go" operations. 

RBMOV Nonpermanent storage for programs to be 

executed. 

RBMS2 Storage for Extended Symbol standard 

procedures. 

RBMSYM RBM Symbol Table of Monitor service 

routines. 

RBMID Holds IDNT origins for Debug. 

RBMAL Used by the accounting routine. 



If a 32 user accepts the default allocation for the RBMGO, 
RBMOV, RBMAL, RBMID, RBMS2, and RBMPMD files, no 
modifications via the RAD Editor have to be made for these 
files. 

The RBM Symbol Table contains the definitions (DEFs) for 
the Monitor service routines. These DEFs are needed by 
the Overlay Loader at load time to satisfy any reference to 
the Monitor service routines. The first word of the table 
contains the number of bytes in the table, followed by seven 
words per entry, in the same format as in the Overlay Loader 
Symbol Table. 

After the System Load Processor completes its writing of the 
system data area, it moves the RAD bootstrap to memory 
locations through 63 and transfers control to the bootstrap. 
Then the bootstrap goes through its normal loading proce- 
dure (described in "Initial Loading of System Processors"). 



INITIAL LOADING OF SYSTEM PROCESSORS 

For a complete system load, the first processor that is loaded 
must be the Overlay Loader. The Overlay Loader is coded 
in a self-relativizing format and is loaded by the RBM Abso- 
lute Loader. An entry in the System Processor Dictionary 
for the Overlay Loader will be made at SYSLOAD time. 
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The object module of the Overlay Loader will be loaded 
from the AI device and written into its assigned file. The 
user must precede the loading of the Overlay Loader with 
an SY key-in and an IASSIGN OV=OLOAD, SP control 
command. 

After the Overlay Loader has been loaded onto its perman- 
ent file, it is available to load a relocatable binary deck 
of the RAD Editor onto the RBMOV file of the RAD. The 
RAD Editor is then executed via an !XEQ command and 
makes an entry for itself in the System Processor area by 
means of an !*ADD control command. It then should be 
copied onto its defined file. At this point, the System 
Processor area of the RAD contains the Overlay Loader 
and the RAD Editor, which are the oniy processors needed 
to complete the loading of other programs. 



PUBUC LiBRARY CREATION OR UPDATING 

The Public Library can be created after the Overlay Loader 
and RAD Editor have been loaded and thereafter can be 
completely regenerated any time the user desires. A file 
with the name PUBLIB will have to be defined via the RAD 
Editor in the User Processor area for the Public Library, and 
a file named LIBSYM must be defined in the System Data 
area of the RAD. The relocatable binary decks of all rou- 
tines to be specified as being in the Public Library are 
loaded by the Overlay Loader (via the !$PUBLIB control 
command) and an absolute core image version is written by 
the Overlay Loader on the RAD file defined as PUBLIB. 
Before executing the Overlay Loader, the operator must key 
in SY so that the Loader can write in a protected RAD file. 

When a Public Library is successfully loaded, additional up- 
dating of RAD files will be done by the Overlay Loader. 
The Public Library Transfer Vector Table will be input from 
the RAD and either created (for an initial load) or updated 
for succeeding loads. This process consists of linking each 
Public Library definition (DEF) in the Symbol Table to a 
transfer vector, and linking the transfer vector to the value 
of the DEF. When the linkage is completed, the Overlay 
Loader writes the new Public Library Symbol Table into a 
previously defined file (called LIBSYM) in the system data 
area of RAD. For an initial load, this file will be previ- 
ously defined, via the RAD Editor, with the name LIBSYM. 
The new Transfer Vector Table is then written on the RAD (re- 
placing the previous one), and the Loader exits toM:TERM. 
(Note that RBM must be rebooted from the RAD in order to 
load the Public Library into core memory.) The Public 
Library should not be loaded into core (by rebooting the 
system from the RAD) until the user has reloaded all fore- 
ground and background routines that use the Library. 



RESIDENT FOREGROUND CREATION OR UPDATING 

In an initial load the resident foreground files must be de- 
fined via the RAD Editor. These files must be in the User 
Processor area (UP) of the RAD. Also, the parameter on 
the FAUU command specifying that this is a resident fore- 
ground file will have to be set. One RAD file can be de- 
fined for each foreground program, thus allowing an update 



to be done on a program basis as opposed to the entire 
resident foreground area. On an initial load the Overlay 
Loader reads in a relocatable binary deck of each fore- 
ground program, and creates an absolute core image version 
of the program in its predefined RAD file. Foreground pro- 
grams assembled as absolute sections must be loaded with an 
ABS control command. Prior to executing the Overlay 
Loader, the user may key in SY to specify that the protected 
RAD files can be written on. 

For an update, only those programs being modified need be 
reloaded. However, if a program exceeds its allocated core 
space, other programs must be reloaded and relocated at a 
new absolute address in a different area of core. 

The Overlay Loader (or the Absolute Loader) will store in 
the first sector of each file the appropriate header informa- 
tion that the RBM bootstrap needs to load and initialize each 
foreground program. The information needed by the boot- 
strap consists of the following items: 

1 . Load address. 

2. Number of bytes in program. 

3. Entry address of initialization routine (if present). 

If no initialization routine is specified, the RBM bootstrap 
will initialize the task's interrupt level from information in 
the TCB. The task may also be triggered at this point if the 
TCB so specifies. 

After the resident foreground is loaded on the RAD, it is 
brought into core by manually rebooting the system from 
the RAD. It can also be brought into memory by inputting 
a Iprocessor or !XEQ command with OV assigned to its 
RAD file. 



When core is reloaded from the RAD, all newly loaded 
Public Library and/or resident foreground programs will be 
loaded and executed, if appropriate (see the description of 
the RAD bootstrap process at the end of this chapter). 

When it is desired to test a new version of a resident 
foreground program in core before it becomes permanent 
on the RAD, it can be loaded and executed from the 
RBMOV file. After the program has been tested, it can 
be loaded permanently on the RAD using the previously 
described procedure. 



NONRESIDENT FOREGROUND CREATION OR UPDATING 

Nonresident foreground programs can be created or updated 
in their predefined RAD files at any time. The Overlay 
Loader will read in relocatable binary decks of the nonresi- 
dent foreground programs, convert their addresses to absolute 
form, and write them into their defined files. The nonresi~ 
dent foreground flies wiM be located in the user processor 
area of the RAD, and the definition of the files will be 
accomplished by the commands to the RAD Editor. 
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SYSTEM PROCESSOR AND LIBRARY CREATION 



REBOOTING THE SYSTEM FROM RAD 



The system processors (Extended Symbol, RAD Editor, Basic 
FORTRAN IV, Concordance, and Utilities) can be loaded 
or updated by the Overlay Loader from relocatable binary 
decks. These processors will have their address converted 
to the absolute locations appropriate for the background 
area and will be written onto their predefined files in the 
system processor area. Any processor can then be executed 
by input of the appropriate !xxx command (where xxx is the 
file name of the processor). 

The System Library will be input in relocatable binary form 
by the RAD Editor and written in relocatable binary form 
onto the system library area of the RAD. The construction 
of several dictionaries in the system library is performed by 
the RAD Editor. 



SYSLOAD ALARMS 

In addition to the RELOAD alarms listed previously and those 
concerned with loading RBM Part 2, the alarms given in 
Table 30 can be generated and are unique to SYSLOAD. 



The system can be rebooted from the RAD by manually 
causing sector zero of the system RAD to be loaded, or by 
reading in the RAD bootstrap previously punched on the 
BO device. The RAD bootstrap will initially move itself 
to high core and then read in RBM from the system pro- 
cessor area of the RAD. The information necessary to read 
in RBM is contained in the last cells of the bootstrap and 
is supplied by SYSLOAD when the bootstrap is written on 
the RAD or punched out. After the resident portion of RBM 
is loaded, control is transferred to another bootstrap that 
loads the remainder of the RAD. This bootstrap functions 
in the overlay region of the RBM. 

The second bootstrap initially inputs the Transfer Vector 
Table to complete the loading of the resident portion of 
RBM. Next, an attempt is made to assign an operational 
label to the PUBLIB file in the user processor area. If a 
Public Library is present, the assignment will be made, 
and the bootstrap then inputs the Public Library. If DATA 
switch 4 is set, the Public Library will not be loaded. After 
the Public Library is processed, the Hex Corrector (see 
Appendix G)will be activated if DATA switch 1 is set. The 



Table 30. SYSLOAD Alarms 



Message 


Meaning 


Recovery 


CP AREA TOO SMALL 


The size of background has changed 
and/or RAD area allocated for a 


To perform checkpoint, SYSLOAD will have 
to be rerun using the ALL option. 


INVALID PARAMETER 


An invalid input has been made to the 
INPUT OPTION request. 


Retype either ALL or UPD. 


UN PROTECT RAD 


One of the write-protect switches has 
been set on the RAD for an area that 
SYSLOAD is attempting to modify. 


Remove the write protection for the appro- 
priate area. 


EOT ON SP AREA 


An end-of-tape status has been re- 
turned while writing on the SP area. 
Not enough room has been allocated 
for the SP area. 


A new SYS GEN will have to be run with an 
increase in the SP area. 


EOT ON SD AREA 


Same as for SP, except the SD area has 
overflowed. 


Same as for SP. 


RDdn FAULT 


A nonexistent address has been given 
for a seek operation. 


Check RAD allocation parameters in 
SYSGEN for allocation of more tracks than 
exist on this RAD. Repeat SYSGEN and/or 
SYSLOAD as necessary. 


MASTER DICTIONARY 
OVFLOW 


Version of RBM on RAD has a larger 
Master Dictionary than new version. 


Last areas of old dictionary were lost. A new 
SYSGEN may be necessary. 


UPDATE UNSUCCESSFUL 


The previous Master Directory could 
not be located. 


The new SP area must be at the same RAD 
address as the previous SP area, otherwise 
the ALL option must be used. 
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bootstrap then searches the User Processor Dictionary for 
all files flagged as a resident foreground file. All such 
files are input, one file at a time, and an initialization 
routine is executed if one exists. The initialization routine 
can do any required housekeeping (such as repositioning 
all appropriate files), arm and enable the appropriate 
interrupts, and then return control to the bootstrap. The 
initialization routine is linked by an RCPYI P,L instruc- 
tion. It then expects to have control returned to the ad- 
dress in the L register. Hence, the bootstrap wili read in 
the resident foreground programs, one by one, and execute 
any initialization routine. 



A provision is made to reboot the system without loading 
resident foreground. This is accomplished by setting DATA 
switch 3 just before clearing the 
the initial RAD bootstrap. 



11.1,^:4." rlrila 
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The system is then completely rebooted and the bootstrap 
sets the protection registers, outputs the following messages, 
and enters a "wait" state. 



! 1AFTER 'WAIT' SET PROTECT 

NSET PARITY TO 'INT.' 

!! KEY-IN AN 'S' TO BEGIN 



'ON' 



If the computer enters a "wait" state before the above mes- 
sages are output, the bootstrap was not successful in loading 
the required data. This would usually be caused either by 
a parity error while reading the RAD or by a faulty fore- 
ground program. 

The above messages may be inhibited by setting DATA 
switch 2 prior to execution of the bootstrap. The indicated 
operations must still be performed, however. 

Thfi iQdd '"C! O^ rocirJont fnronmi inA frin np Innlnltpfl hv spt— 

ting DATA switch 3 before executing the initial bootstrap. 
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12. DEBUG 



INTRODUCTION 

This chapter describes the use of Debug and its interface 
with RBM. 



GENERAL DESCRIPTION 

The RBM Debug package is a debugging tool primarily de- 
signed for nonoverlaid background programs, with limited 
facility for foreground programs. It provides the user with 
the following capabilities: 

1. To transfer control to the control device from a speci- 
fied location in the user's program or through the Con- 
trol Panel Interrupt. 

2. To dump selected core and registers on the keyboard/ 
printer or the line printer. 

3. To modify memory locations and registers. 

4. To logically insert code at specified memory locations. 

5. To begin or continue execution at a specified memory 
location (i.e. , selective execution). 

6. To perform conditional memory dumps (snapshots) of 
registers and selected core locations at a specified 
location and optionally transfer control to the con- 
trol device. 

7. To step through a program. 

FOREGROUND USER'S DEBUG CAPABILITY 



Debug can be used to aid the checkout of a foreground pro- 
gram operating at priority levels lower than the Control 
Panel Interrupt level. To accomplish this, Debug is moved 
to the Control Panel Interrupt level, where if may be di- 
rectly entered by pressing the Control Panel Interrupt switch. 
The Control Task remains at the lowest interrupt level. 
Key-ins requesting Control Task functions may be made by 
typing NEW LINE (©) in response to the DKEYIN message. 
Snapshots may be placed in all tasks whose interrupt level 
is lower than the Control Panel Task. 



OVERLAY USER RESTRICTIONS 



When a snapshot is inserted in a currently resident seg- 
ment using a Debug control command, the snapshot is 
valid only until the segment is overlaid, since Debug 
operates only at execution time on resident programs. 
This problem is reduced by allowing the user to assem- 
ble Debug calls into his program. 



RBM AND FOREGROUND USER'S INTERFACE 

Debug is normally a subtask of the RBM Control Task with 
a priority just below the IDLE subtask. Debug is triggered 
by any of the three resident Monitor routines (D:SNAP, 
D:KEY, or D:CARD), by the KEYIN subtask, or by the Job 
Control Processor (JCP). JCP triggers Debug when it re- 
ceives an XED command, and the system loader transfers 
control via D:KEY. When a foreground user wishes to use 
Debug, he gives control to Debug by an !XED card or by 
an unsolicited key-in of DE. After Debug has control, the 
foreground user moves Debug to the Control Panel Task level 
with a Define command. After debugging, the foreground 
user issues the Debug command Q which restores Debug to 
its original level. 



MEMORY REQUIREMENT AND INSERTION 
BLOCK DEFINITION 

The executive portion of Debug is a foreground program that 
may be resident or nonresident. If the program is resident, 
it must be so specified when the Debug file is created with 
the RAD Editor. It is read into core when RBM is booted. 
If the program is nonresident, it is loaded like any other 
foreground program (see Chapter 6). Debug has the follow- 
ing core memory requirements: 



1. Executive 

2. Zero table 

3. Overlays 

4. Insertion block 



440 locations 
35 locations 
RBM overlay space 
User-defined 



The insertion block is an area of core that stores user- 
inserted code, and the zero table cells are used to refer- 
ence these insertions (see Appendix B). 



DEBUG CONTROL 

Control can be given to Debug in the following ways: 

1. A direct call to Debug. 

2. The execution of a snapshot. 

3. An unsolicited key-in of DE. 

4. The Debug execution card (!XED). 

5. Control Panel Interrupt (see Foreground Capability, 
above) . 

A direct call on Debug is a user-coded request for Debug to 
read a command. The call has the form 

RCPYI P,A 

B D:KEY or D:CARD 
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When the entry Is D:KEY, Debug prints the message 



MDKEYIN 



A Debug command will then be read from the proper device - 
file number assigned at SYSGEN. 

Note thatafter the initial directcall on Debug a foreground 
task will have to exit in order to move Debug to a higher 
interrupt. 

D:KEY, DrCARD, DrSNAP (snapshot) are small reentrant 

routines that actually trigger Debug. An unsolicited key-in 
I during Debug will not harm the user's environment. The 
I IXED command performs the same function as the SXEQ 

command except that Debug is called via D.=KEY before 

executing the user's program. 



DEBUG COMMANDS 

After Debug has control, it interprets the following 
commands: 



Code Function 

D Define 

I Logically insert code 

S Insert snapshot 

X Step (move) snapshot 

R Remove snapshot or insertion 

T Perform selective dump on keyboard/ 

printer and Debug output device 

P Perform selective dump on Debug output 

device 

C Set Debug input device to the card reader 

K Set Debug input device to the keyboard/ 

printer 

M Modify memory 

B Branch (i.e., return control to program) 

E Exit from interrupt level 

Q Terminate Debug 



Most Debug commands specify registers and memory loca- 
tions. Registers are specified as follows: 

RP Program address register 

RL Link address register 

RT Temporary register 

RB Base address register 

RX Index register 

RE Extended accumulator 

RA Accumulator 

RR All of the above 

Locations are specified in one of the foi lowing forms: 

1. One to four hexadecimal digits. 

2. SNAME, where NAME is an IDNT and its value is the 
load origin of such module. The Overlay Loader D 
option must be invoked if the user is to use IDNT names 
with Debug. 

3. Sums or differences of values of either of the above two 
forms. 

Examples: 

A14 
SSQRT 

ABC+SSUB1+1492 
SSUB1 - SSUB2 

If the SNAME option is invoked, the user must define an in- 
sertion block (see the Debug Define command, below), and 
the last K:BLOCK words of the insertion block are used as 
a buffer for the IDNT names. 

D (Define) 

The Define command is used to define an insertion block 
when the Debug commands S or I or the SNAME option is to 
be used. 

The form of the Define command is 

\ D [start, end] [,CP] 



Debug uses MrREAD and M:WRITE for input/output; and 
hence the keyboard character NEW LINE terminates a line, 
EOM deletes a line, and cent (/) deletes the previous 
character. Debug Interprets the semicolon character (;) 
(if not in the message field of a snapshot) as a continua- 
tion character. The semicolon will terminate the line (or 
card and continue the command to the next iine (or card). 
Blanks are ignored except within the message field of a 
snapshot. 



start is the memory location of the first cell of the 

insertion block. 

end is the memory location of the last cell of the 

insertion block. 

CP is an optional request to move Debug to the 
Control Panel Interrupt level. The default level 
is the RBM Control Task level. An unsolicited 
key-in of FG must be in effect when the level is 
specified. 
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I (Insert) 

The Insert command designates the insertion of one or more 
instructions logically before (IB), after (IA), or replacing 
(IR) the instruction at the designated location (loc). 

The form of the Insert command is 



loc,inst 1 , , 



,inst 



where 

IB designates Insert Before 

IA designates Insert After 

IR designates Insert Replace 

The instructions may be designated in one of the following 
forms: 

1. op*loc 

where op isa two-digit hexadecimal value representing 
the operation code and address modification. The sec- 
ond digit (i.e., address modification) must be one of 
the following: 

designating direct addressing 

2 designating indexing 

4 designating indirect addressing 

6 designating indirect addressing and indexing 

This instruction form relieves the user of creating the 
actual address structure for Sigma 2/3. It does not apply 
to the conditional branch instruction (operation code 
6) nor to the register copy instructions (operation 
code 7). Debug will actually expand an instruction 
designated in this form into more than one instruction; 
for example, 82*1492 will expand into 

8E02 LDA *$+2, 1 

4802 B $+2 

1492 DATA X'1492' 

See Appendix J for a description of the expansions. 

2. 6x*loc 

where x designates the desired conditional branch; 
for example, 6E*1492 designates a BAN 1492 and will 
expand into 



6E02 BAN 
4803 B 
4C01 B 



$+2 
$+3 
*$+l 



1492 DATA X'1492' 
See Appendix J for a description of the expansions. 



3. hex value 

which is inserted with no expansion. 

4. Any mnemonic copy instruction in the Sigma 2 and 
Sigma 3 Computer Reference Manuals. The comma 
between the register specifications must be omitted. 

The results of an insertion are defined in Appendix N. 

An example of the insert command is as follows: 

IB$SUB+1000, 80*$SUB+25, 75A1, 40*$SQRT+0,; 
RCPYIPL,ROR*LT,REOR XB 

S (Insert Snapshot) 

The Insert Snapshot command inserts (in the same manner as 
the instruction Insert Before) a snapshot at the designated 
location so that when control passes through loc, the fol- 
lowing transpires prior to executing the instruction that was 
at loc: 

1. The optional conditions are evaluated, and if false, 
the snapshot is bypassed. 

2. If the conditions are true (or if none are specified), the 
following is output: 

SNAP AT loc 

message (if any) 

followed by the designated dumps. 

Such output is always transmitted to the Debug output de- 
vice; and if any of the dumps designate the keyboard/ 
printer, then the SNAP and the message line also will be 
transmitted to the keyboard/printer. A user can make a 
maximum of 32 snapshot and instruction insertions. (See Ap- 
pendix L for the calling sequence for a Snapshot command.) 

The form of the Insert Snapshot command is 




S| " x | locf/conditions/jfjmessage'jf^ump requests] 



S is a request to snapshot and resume execution. 

SK is a request to snapshot and transfer control to 

the keyboard/printer for Debug input. 

SS is the same as SK, but may be stepped (see 

Debug command X. ) 



conditions 
message 
dump requests 



are as described below. 
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Conditions. The format of the conditions is 



{f}'2lf}'3-{fk 



where r. is a relational expression of the form 



constant 



register 



H 





loc 


< 




> 

* 

< = 


constant 


> = 




<> 


register 



where constant is the same form as a loc preceded by a *; 
for example, 

#1492 or # SSUB+57 

The meaning of the operations in hierarchical order are 
as follows: 



— 


equal 


< 


less than 


> 


greater than 


< = 


less than or equal to 


> = 


greater than or equal to 


<> 


not equal 


& 


logical and 


1 


logical or 



The comparison is arithmetic unless the operator is preceded 
by an asterisk (*), in which case the comparison is logical. 

Message. Message is a string of any EBCDIC characters ex- 
cept quote ('). 

Dump Requests. The format of the dump requests (if any) is 
., [T]. 



[T] 



register 
loc 



I oc . . . I oc 



register 




loc 




1 oc ... 


loc 



where T designates a particular dump to be output on both 
the keyboard/printer and the Debug output device. If T is 
absent, the dump will be output to the Debug output device 
only. Only one dot (. ) is necessary in specifying a block 
of memory locations. Extra dots are ignored. 

An example of the snapshot command is as follows: 

S$SUB+505/RA=# 0&1492<1496/ , TAB1 FULL', 
STAB 1... STAB 1+256, RR 

X (Step Snapshot) 

If control is at the Debug input device as a result of a 
stepping snapshot (SS), the X command moves the snapshot 



to memory location n, keeping the same conditions, mes- 
sage, and dump requests. Control is then transferred to the 
branch location. 

The form of the Step Snapshot command is 



X [n[,branch]] 



r 



where 

n is the memory location. 

branch is the branch location. 

If the snapshot was executed at location ALPHA the de — 
fault cases are branch = ALPHA and n = ALPHA+1. 

R (Remove Snapshot or Insertion) 

The Remove command restores the displaced instruction to its 
original memory location. The command releases the zero table 
entry and, if the entry is the latest snap or insertion, re- 
leases its space in the insertion block. Note that the space 
in the insertion block is regained only if the Remove com- 
mand affected the latest entry in the insertion block. 

The form of the Remove command is 

/K loc, , loc— . . ., loc 1 

where loc is the memory location. 

T (Selective Dump on the Keyboard/Printer and the 

Debug Output Device) 

The T command outputs the contents of the requested loca- 
tions and registers in hexadecimal on both the keyboard/ 
printer and the Debug output device. Console interrupt 
will transfer control to the keyboard/printer after the cur- 
rent line is output. 

The form of the T command is 



(' 



T dumps 



where dumps (i.e., dump requests) have the following forms 
(there can be several dump requests in any order separated 
by commas): 



loc 


SSUB+3 




loc . . . loc 


$SUB.. 


3FFF 


register 


RA 




all registers 


RR 
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P (Selective Dumps on the Debug Output Device) 



Examples of the M command are 



This command is identical to the T command except that the 
dumps go only to the Debug output device. 

The form of the P command is 

A? dumps 

C (Debug Input Device) 

The C command gives control to the Debug input device. 

The form of the C command is 



A 



K (Keyboard/Printer) 

The K command gives control to the keyboard/printer. 

The form of the K command is 



M (Modify Memory) 

The M command modifies memory locations or registers. 

The form of this command may be either of the following: 



A 



M register,word 




loc,word_, . . . ,word 
U n 



1. M$SUB+1, 4, 1, $SUB+2, RADDIZE 

where the following cells are modified if SUB is lo- 
cated at 100, 





16" 


Loc 


Value 


0101 


0004 


0102 


0001 


0103 


0102 


0104 


7C68 



2. MRA, $SUB 

This sets the A register to 0100. Note that an MRP 
command will change the program address portion of 
the program status doubleword. 

3. MT 149A, RCPYIPA 

This will produce the following output if the contents 
of location 149A was FFFF prior to the command 
149A: FFFF — 75F1. 

B (Branch) 

The Branch command allows the user to insert loc into the 
program address portion of the program status doubleword 
and to exit from Debug. If loc is not present, the user just 
exits from Debug. 

The form of the Branch command is 
B [loc] 



E (Exit From Interrupt Level) 

The E command allows the user to force an unusual exit from 
the highest active interrupt level below Debug. Debug will 
still have control after this command. 

The form of the E command is 



loc is the first memory location to modify. 

wordj is the hexadecimal value (or mnemonic reg- 

ister operation; see item 4 under the Debug I 
command) to be stored in the designated register 
or at location loc+i. 



P if present, is a request to print the hexadecimal 

value of the effective location, its previous value, 
and its new value. 

T if present, is a request to type the hexadecimal 

value of the effective location, its previous value, 
and its new value. 



Q (Quit Debug) 

The Q command causes Debug to reset its internal flags and 
zero table cells, restore RBM's original interrupt level, 
trigger the Job Control Processor, and exit. If the X option 
is present, Debug will also disconnect (i.e., unload) itself 
from the system. 

The form of the Q command is 
Q [X] 
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DEBUG ERROR MESSAGES 



Error messages are shown below: 



Message 



Meaning 



ERROR SYNTAX Syntax error 

ERROR COMMAND Command error 



ERROR FOREGRND 



Command attempt's to affect 
foreground without a hard- 
ware interrupt level specified 
for Debug (see Debug D 
command^ 



Message 

ERROR OVERFLOW 



ERROR IN/OUT 



Meaning 

Either insertion block or zero 
table overflow 

Input/output error 

When Debug encounters an error, it aborts a background job 
if there is no ! ATTEND card. Otherwise it requests further 
commands from the keyboard/printer. At this time, Debug 
will not have modified the environment, aiiowing the user 
to attempt recovery. (It is assumed that the user will respec- 
ify any erroneous commands.) 

A KEYIN error message issued as the result of an unsolicited 
key-in of DE, or an abort code of DE issued as the result of 
a direct call on Debug, implies that Debug is not part of the 
system. This can be corrected by queuing in Debug (i.e., 
an unsolicited kev-in of Q DEBUG). 
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APPENDIX A. SIGMA 2/3 STANDARD OBJECT LANGUAGE 



INTRODUCTION 

TheXDS Sigma 2/3 standard object language provides a means 
of expressing the output of a processor in a standard format. 
All programs and subprograms in this object format can be 
loaded by the XDS Sigma 2/3 Overlay Loader. The complete 
standard object language contains 13 load item types. 

An object module consists of the ordered set of binary rec- 
ords generated by an assembly or compilation for later load- 
ing. The Overlay Loader has the facility to load and 
link several object modules together to form an executa- 
ble program. 

The Sigma 2/3 RBM System Absolute Loader can load a single 
module (absolute subset) to form an executable program. 
The following load item types from the standard object lan- 
guage comprise the absolute subset: 

1 . Record Header 

2. Record Padding (type 0, subtype 0) 

3. Repeat Load (type 0, subtype 1) 

4. Unrelocated Load (type 1) 

5. Start Module (type 4) 

6. End Module (type 5) 

7. Absolute Load Origin (type 7, subtype 1) 

All load item types are acceptable input to the Overlay 
Loader except Absolute Load Origin (type 7, subtype 1). 

DESCRIPTION OF OBJECT MODULES 

GENERAL DESCRIPTION 

An object module consists of a set of binary object records, 
each containing an integral number of load items after a 
standard three-word record header (see Figure A-l). Each 
binary record in the module is a 120-byte record. 







First Record 
Second Record 




FF 


n 


Seq. No. 


Checksum 


Load Items 


Nonactive 
Information 








F F 


n 


Seq. No. 1 


Checksum 


Load Items 


Nonactive 

Information 







Figure A-l. Typical Object Module of M Records 
90 10 37F- 1(3/72) 





• 


(M-l)th Record 

Mth Record (Last record of modu 


e) 




F F 


n 


Seq.No.M-2 


Checksum 


Load Items 


Nonactive 

Information 








9F 


n 


Seq. No. M-l 


Checksum 


Load Items 


Nonactive 
Information 







Figure A-l. Typical Object Module of M Records (cont.) 

Each load item consists of a header word followed by a 
variable number of data words. The first load item in an 
object module is a start-module item and the last item (other 
than record padding) is an end-module item. There are 15 
types of load items, described below. 



BINARY OBJECT RECORD FORMAT 

Each 120-byte binary record in an object module consists of 
these parts: Record Header, Load Items, and Nonactive In- 
formation in the following arrangement. The Record Header 
and Load Items are considered the "active" portion of the 
record. 



Record Header 



Load Item 1 



Load Item 2 



3 words 



► up to 51 words 



Load Item n 



Nonactive 

Information 



The "active" portion of the record is that information con- 
cerning type, sequence number, checksum and binary data 
usually processed by loaders. The "nonactive" portion may 
contain sequence or identification information, or it may be 
empty. It is not processed by the loaders. 
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FORMAT OF RECORD HEADER 

The first byte of the record header may be either X'F 1 or 
X'9 1 . X'F 1 denotes that this is a standard record of the ob- 
ject module: X'9 1 denotes that this is the last record of the 
object module. 

word 



Control word 


For 9 | 


F 





n 


n 


n 


n 


n 


n 



3 4 



9 10 11 12 13 14 15 



word 1 



s 


c 


Record sequence no. 









1 2 



word 2 



15 



Checksum 







15 



nnnnnn in the first word is the number of active words in the 
record, excluding the record header. "Active" denotes data 
to be processed by a loader. There may be some padding 
words or sequence information at the end of the record that 
is not included in the "active" count. The maximum value 
of n is 51. Note that although the physical record size is 
fixed at 120 bytes (80 columns of binary data) the number of 
active words may vary from 3 to 54. This effectively stan- 
dardizes the reading of binary object records but allows ver- 
satility in the generation of active data. The record sequence 
number starts at and takes on consecutive integer values 
for all the records in one file. The S bit is a sequence over- 
ride. If this is a 1, the loader ignores sequence checking 
for the record. The checksum is an arithmetic sum, with 
carry, of the n-3 active words after the record header. If 
the C bit is a 1, the checksum is ignored. 

LOAD ITEM FORMAT 

Each load item consists of a one-word header and an op- 
tional variable- length body of data. 



Load Item Header 



Load Item Data 



► Load Item 



FORMAT OF LOAD ITEM CONTROL (Header) WORD 

Every header word has the same general format: 

bits 0-3 Type. 

bits 4-7 Subtype or control. 

bits 8-15 Number of data words in the load item (ex- 
cluding item header). 

This number plus 1 is equal to the size of the 
load item. All words of a load item must be 
contained in the same physical record. 



SUMMARY OF LOAD ITEM FORMATS 

RECORD PADDING (Type 0, Subtype 0) 
word 



Control word 




























3 4 



7 8 



11 12 



15 



There is no body of data. Padding words are ignored by the 
loader. The object language allows padding as a conve- 
nience for processors. 



REPEAT LOAD (Type 0, Subtype 1) 
word 



Control word 











1 








1 



3 4 



11 12 



15 



word 1 



Repeat count 







15 



This item repeats the next load item a specified number of 
times. The load item (type 1, 2, or 3 only) immediately 
following the repeat load is repeated (i.e., loaded) in its 
entirety the number of times indicated by the data word. 



UNRELOCATED LOAD (Type 1) 
word 



Control word 



0l[0000|0 0nn|nnnn| 



3 4 



11 12 



15 



word 1 



First data word 



15 



word n 



Last data word 



15 



This item loads n words without relocation. 



RELOCATED LOAD-MODULE BASE (Type 2) 



word 



Control word 








1 











n 


n 


n 


n 


n 


n 



3 4 



11 12 



15 
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word 1 



First data word 



15 



word n 



Last data word 







15 



This item loads n words with module relocation. The reloca- 
tion bias of the current object module is added to each data 
word in the item. 

RELOCATED LOAD-COMMON BASE (Type 3) 

word 



Control word 





1 1 








n 


n 


n 


n 


n 


n 



3 4 



11 12 



15 



word 1 



First data word 



15 



word n 



Last data word 



15 

This item loads n words with a common base relocation. 

START MODULE (Type 4) 

word 



Control word 





1 








n+ 1 



3 4 



15 



word 1 



Common size allocation 




word 2 



15" 



First character 



Second character 



15 



word n + 1 



(2n-l)th character 



Last character (or blank) 







7 8 



15 



This item identifies the start of the object module. The 
characters in words 2 through n + 1 are the program name 
(identification) for the module. 



END MODULE (Type 5) 
word 



Control word 





I 1 r 





1 


1 



3 4 



7 8 



11 12 



15 



word 1 



Starting address 




word 2 



15 



Severity level 




word 3 



15 



Relocatable size (or zero) 







15 



This item identifies the end of the object module. In the 
control word (word 0), the starting address is defined in 
bit 7 

where 

r = 1 indicates absolute starting address, 
r = indicates relocatable starting address. 

The severity level in word 2 is defined as the highest level 
reached during processing. 

The loader uses the relocatable section size, if present, rather 
than its own location counter to determine the starting loca- 
tion for the next relocatable section. 

A starting address of absolute indicates there is no starting 
address for this module. 

LOAD ORIGIN (Type 7) 

word 



Control word 


1 


1 1 


r 





1 



3 4 



7 8 



11 12 



15 



word 1 



Origin address 



15 



This item sets the origin within the object module. In the 
control word (word 0), the origin is defined in bit 7 



whe 



r = indicates relocatable origin. 
r = 1 indicates absolute origin. 
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RELATIVE LOCATION POINTER (Type 8) 
word 



Control word 


10 


r 





1 


3 4 7 8 11 12 15 
word 1 


Chain base address 









15 



This item establishes the chain base for later chain resolu- 
tion. In the control word (word 0), the chain base address 
is defined in bit 7 



/here 



r = indicates a relocatable address, 
r - 1 indicates an absolute address. 



NAME DEFINITION (Type 9) 
word 



Control word 



1 10 10 



n+ 1 



3 4 



7 8 



15 



word 1 



First data word 




word 2 



15 



I ii si i.i iui uCFSi 



I SsCOP^ rtinrnrtpr 



15 



word n + 1 



(2n-l)th character Last character (or blank) 



0. 



15 



This item identifies a name as a definition within the object 
module. 



All name definitions immediately follow the start-module 
item and must precede all other load items. For each name 
definition, an address definition should appear later in the 
object module. 



word 1 



First data word definition — address 




word 2 



15 



First character 



Second character 



IS 



word n + 1 



(2n-l)th character 



Last character or blanks 



7 8 



15 



This item associates a location in the module with a defini- 
tion name (characters in words 2 through n + 1) for other 
modules to reference. In the control word (word 0), the 
definition address is defined in bit 7 

where 

r = indicates relocatable definition address, 
r = 1 indicates absolute definition address. 

EXTERNAL REFERENCE (Type A) 

word 



Control word 


1 





1 r 


n+ 1 



3 4 



15 



word 1 



Chain address (or zero) 




word 2 



15 



First character 



Second character 



15 



word n + 1 



(2n-l)th character 



Last character (or blank) 



15 



This item states a name (characters in words 2 through n+ 1), 
defined in another module, whose definition address must be 
inserted in a chain of locations within the module. In the 
control word (word 0), the chain address is defined in bit 7 



ADDRESS DEFINITION (Type 9) 



word 



Control word 


1 





1 J 


r 


n + 1 



3 4 



7 8 



15 



r - indicates a relocatable chain address. 



=: nn .-ikc-.liii-e r-kr-An «rW«»« 



r — i inuiCQieS an uuSGiuiS CiiO 



Note : If there is no chain address, the reference address is 
zero and is used for library searching purposes only. 
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SECONDARY REFERENCE (Type B) 
word 



Control word 


10 11 





r 


n + 1 



3 4 



15 



word 1 



First data word chain address 




word 2 



15 



First character 



Second character 



7 8 



15 



word n + 1 



(2n-l)th character 



Last character (or blank) 







7 



15 



This item states a name (characters in words 2 through n+ 1), 
defined in another module, whose address may be inserted 
in a chain of locations within the module. This item is iden- 
tical to type A, above, except that it does not force loading 
of the routine from the library. In the control word, the 
chain address is defined in bit 7 



r = indicates a relocatable chain address, 
r = 1 indicates an absolute chain address. 

ADDRESS LITERAL CHAIN RESOLUTION (Type C, sub- 
types 0, 1, 2, and 3) 

word 



Control word 


1 1 q r 











1 



word 1 



Resolution address 



15 



word 2 



Chain address 







15 



This item defines a location within the module (called the 
resolution address) whose address must be inserted in a chain 
of displacement fields within the module. In the control 
word, the chain address is defined in bit 6 



q =0 indicates a relocatable chain address, 
q = 1 indicates an absolute chain address. 



The resolution address is defined in bit 7 

where 

r = indicates a relocatable resolution address, 
r = 1 indicates an absolute resolution address. 

An address literal chain is a threaded list of forward refer- 
ences to a single location in a program. The definition 
value (called the resolution address) can be output as an 
address literal chain resolution (Type C, subtypes 0, 1, 2, 
and 3). The chain address points to the beginning of the 
threaded list which is terminated by an absolute zero value. 
The resolution address and the chain address may be absolute 
or relocatable. 

Note: Because the terminator of the chain is zero, no pro- 
gram may have an address literal chain whose last 
link is at absolute zero (i.e., the item would refer- 
ence zero and would thus appear to terminate the 
chain). 

Note that external reference (REF) (type A) and secondary 
reference (SREF) (type B) chains are structured in the same 
manner, but resolved by the loader using an external defi- 
nition value (type 9). 

DISPLACEMENT CHAIN RESOLUTION (Type C, subtypes 
6, 7, A, and B) 

word 



Control word 



110 



p p q 



3 4 



10 



7 8 9 



11 12 



15 



word 1 



Resolution address 



15 



word 2 



Chain address 







15 



This item defines a location (called the resolution address) 
within the module whose relative displacement must be in- 
serted in a chain of displacement fields within the module. 
In the control word, the displacement chain is defined in 
bits 4-5 



pp = 01 indicates that an indirect bit is not set in each 
instruction in the displacement chain. 

pp = 10 indicates that an indirect bit is set in each 
instruction in the displacement chain. 

q = 1 always indicates absolute displacement of the 
last item in the chain (relative to the chain 
base declared in item type 8). 
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The resolution address is defined in bit 7 

where 

r = indicates a relocatable resolution address, 
r = 1 indicates an absolute resolution address. 

When forward references occur during one-pass processing, 
and the possibility of resolving the reference by a definition 
or literal may occur within 255 locations, the 8-bit dis- 
placement field of the instruction may be used to form a 
displacement chain. The item types 8 (relative location 
pointer — establish chain-base) and C (displacement-chain 
resolution) must be used together to resolve the chain by 
substituting actual displacements determined at load time. 

In the creation of a displacement chain, the pointer in the 
type 8 item defines the relative location in the program to 
be established as the chain base. Each new type 8 item can 
define a new chain base. The values in the displacement 
field of the instructions included in any given displacement 
chain refer to the absolute displacement of that instruction 
relative to the currently established chain base; e.g., if the 
chain base is established to be X'100' and an instruction is 
located at X'125', the displacement of that instruction for 
purposes of the displacement chain is X' 125'-X' 100' or X'25'. 
This point is emphasized since the loader will use this dis- 
placement only to determine the final displacement of the in- 
struction relative to the location of literal or target locations. 

When the displacement chain connects instructions that ref- 
erence a literal or a specific target location within range of 
the chain base (e.g., LDA=3 LDA=LAB, B XR), no indirect 
bit is set in each instruction (pp = 01 in Header — Type C). 

When the chain connects references to an external symbol 
or forward reference whose value will be given in some lit- 
eral within range of the chain base, pp is set to 2 in the 
type C header, to set the indirect bit in each instruc- 
tion in the chain (e.g., LDA X, which will be resolved 



as LDA *$+n, where n is the displacement of ADRL X rel- 
ative to the instruction). 

The chain base address (in the type 8 item) may bedeclared 
as an absolute or relocatable value. The resolution address 
(first data-word of a Type C item) is the address of the target 
location or literal expressed as a location, and not as a dis- 
placement on the chain base. Note that although the reso- 
lution address is defined at this point, the value of the literal 
at that resolution may not be defined until later. In fact, it 
may be an element of an address- literal chain (type C) or 
external reference chain (type A). The address- literal or 
external chain resolution is independent of the displacement 
chain resolution. 

The chain address given in the second data word is the ab- 
solute displacement of the iast item in the chain, relative 
to the chain base declared in type 8 (e.g., if the effective 
chain base were X 1 1000' and the value of the chain address 
were X'20 1 , the last item of the displacement chain would 
be located at X' 1020'). 

A separate displacement chain will be created for each 
unique variable in a given displacement region. Thus, many 
displacement chains may be built using the same chain base. 
As a matter of fact, the chain base may not be changed until 
a displacement chain resolution item has been output for 
each displacement chain. An unresolved displacement chain 
is a serious error condition in the output, and is unaccept- 
able for execution. 

The format of the displacement chain is described in the 
example in Figure A-2. 

Example: Let a chain base be declared at 109(R). (Numbers 
given are decimal.) It is assumed that the ADRL for XLB 
will be ultimately loaded at 140(R). Note that the displace- 
ment field of each instruction before resolution is a pointer 
to the location of the next item in the threaded list relative 
to the chain base. 



Relative 
Location 
Counter 


Symbolic 


Displacement 
From Chain 
Base 


Displacement 
Field of Instruc- 
tion Before 
Loading 


Displacement 
Field of Instruc- 
tion After 
Resolution 


110 
125 
134 
136 
140 




LDA XLB 
STA XLB 
CP XLB 
STA XLB 




1 
16 
25 
27 


00 (end of chain) 

01 

16 

25 


30(140-110) 
15(140-125) 
06(140-134) 
04(140-136) 




Item Type C, Displacement 
Chain Resolution 












Resolution Address 140(R) 










Chain Address 27(A) 



Figure A-2. Displacement Chain Format 
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LABELED COMMON (Type D, Subtypes 0, 1, and 2) 
word 



Control word 


1 1 


1 








k k 


n+1 



word 1 



3 4 



15 



Labeled COMMON index 



Subtype -(k=0)- Labeled COMMON Definition. This 
subtype conveys the block size in words and an index 
value for the block being defined- The contents of the 
load item designate the alphanumeric name for the La- 
beled COMMON block. The index value is relative 
only to the module being loaded and is sequenced from 
the integer one. It is used only to economize on space 
in the reference and data subtypes. . 

This subtype will follow the start module and name definition 
items. It must precede the reference and data subtypes for 
Labeled COMMON. 



15 



word 2 



Labeled COMMON s?ze / zero, or displacement 



word 3 



15 



Content (first word) 



15 



Subtype 1 -(k=l)- Labeled COMMON References. This 
subtype carries as content a set of words that continue the 
load program and to which a Labeled COMMON base will 
be added. The particular base address to be added is in- 
dicated by the index value in the load item. The word 
to which the base is added may contain positive or neg- 
ative content. Should the index value be zero on this 
subtype, then the blank COMMON will be the added 
base value. 



The third word (word 2) of this item is non-functional and is 
carried as zero. 



word n+1 



Content (last word) 



15 



Subtype 2 -(k=2)- Labeled COMMON Data. This subtype 
will load Labeled COMMON with a set of contiguous 
data. Again the COMMON block is identified by an 
index value. The starting displacement from its base is 
identified in the third word (word 2) of the load item. 
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APPENDIX B. SYSTEM ZERO TABLE AND CONSTANTS 



Table B-l. Monitor Zero Table 



Address 


Name 


Purpose and Assignment 


Dec. 


Hex. 



1 
2 

3 
4 
5 
6 

7 
8 



1 
2 
3 
4 
5 
6 
7 
8 


K:AC 

K:AC1 

K:AC2 

K:AC3 

K:FFLG 

K.-BASE 

K:TCB 

R:IOP 


Reserved for Monitor Use. 

Pointer to Current Floating Accumulator. 

Pointer to Current Floating Accumulator (1). 

Pointer to Current Floating Accumulator (2). 

Pointer to Current Floating Accumulator (3). 

Pointer to Current Floating Flags. 

Pointer to Current Task Reentrant Temp Stack. 

Pointer to Current Task TCB. 

Pointer to 8-word IOP Table. 


9 
63 


9 
3F 




Standard Constants for Foreground, Monitor, and Background 
Use (see Table B-2 for complete list). 


64 
99 


40 
63 




IOCS Pointers and Constants. 


100 
132 


64 
84 




Reserved for Monitor Use. 


133 
134 
135 


85 
86 
87 




Debug Transfer Vector D:KEY. 
Debug Transfer Vector DrCARD. 
Debug Transfer Vector D:SNAP. 


136 
167 


88 
A7 




Reserved for Debug Use. 


168 
198 


A8 
C6 




Real-Time Foreground User Storage (reserved for foreground 
communication between foreground and background or for 
address literals or constants). 
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Table B-l. Monitor Zero Table (cont. ) 



Address 


Name 


Purpose and Assignment 


Dec. 


Hex. 


199 
225 


C7 
El 




Monitor Service Routines Transfer Vectors (see Table 7 for list). 


226 
251 


E2 
FB 




Monitor Constants (see Table B-3). 


252 
255 


FC 
FF 




Counter Interrupt Locations (optional). 







Table B-2. Sta 


ndard Constants 










Add 


ress 


Value 


Address 


Value 


Dec. 


Hex. 


Dec. 


Hex. 


Dec. 


Hex. 


Dec. 


Hex. 


9 


9 


32768 


8000 


20 




14 


16 


10 


10 


A 


16384 


4000 


21 




15 


8 


8 


11 


B 


8192 


2000 


22 




16 


4 


4 


12 


C 


4096 


1000 


23 




17 


2 


2 


13 


D 


2048 


800 


24 




18 


1 


1 


14 


E 


1024 


400 


25 




19 








15 


F 


512 


200 


26 




1A 


-1 


FFFF 


16 


10 


256 


100 


27 




IB 


-2 


FFFE 


17 


11 


128 


80 


28 




1C 


3 


3 


18 


12 


64 


40 


29 




ID 


-3 


FFFD 


19 


13 


32 


20 


30 




IE 


-4 


FFFC 
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Table B-2. Standard Constants (cont.) 



Address 


Val 


ue 


Add 


ress 


Value 


Dec. 


Hex. 


Dec. 


Hex. 


Dec. 


Hex. 


Dec. 


Hex. 


31 


IF 


5 


5 


48 


30 


14 


E 


32 


20 


-5 


FFFB 


49 


31 


-14 


FFF2 


33 


21 


6 


6 


50 


32 


15 


F 


34 


22 


-6 


FFFA 


51 


33 


-15 


FFF1 


35 


23 


7 


7 


52 


34 


-16 


FFFO 


36 


24 


-7 


FFF9 


53 


35 


32767 


7FFF 


37 


25 


-8 


FFF8 


54 


36 


32512 


7F00 


38 


26 


9 


9 


'55 


37 


33023 


80FF 


39 


27 


-9 


FFF7 


56 


38 


65280 


FFOO 


40 


28 . 


10 


A 


57 


39 


255 


00FF 


41 


29 


-10 


FFF6 


58 


3A 


61440 


F000 


42 


2A 


11 


B 


59 


3B 


3840 


0F00 


43 


2B 


-11 


FFF5 


60 


3C 


240 


00F0 


44 


2C 


12 


C 


61 


3D 


49152 


COOO 


45 


2D 


-12 


FFF4 


62 


3E 


31 


IF 


46 


2E 


13 


D 


63 


3F 


127 


7F 


47 


2F 


-13 


FFF3 











Table B-3. Monitor Constants 



Address 


Name 


Purpose 


Dec. 


Hex. 


226 
227 
228 
229 
230 
231 
232 


E2 
E3 
E4 
E5 
E6 

E7 
E8 


KrIOCS 

KrMASTD 

K:PAGE 

KrBACBUF 

KrBACKP 

KrVRSION 


Pointer to IOCS Tables. 

Reserved for Monitor use. 

Pointer to Master Dictionary. 

Number of Lines/Printer Page (SYSGEN Parameter). 

Background I/O Buffer Pooi FWA. 

Protected Background FWA (Start of TCB). 

RBM Version. 
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Table B-3. Monitor Constants (cont.) 



Address 


Name 


Purpose 


Dec. 


Hex. 


233 




E9 


KrPLFWA 


Public Library FWA. 


234 




EA 


KrRFFWA 


Resident Foreground FWA. 


235 




EB 


KrNFFWA 


Nonresident Foreground FWA. 


236 




EC 


KrBACKBG 


Unprotected Background FWA. 


237 




ED 


K:UNAVBG 


Unavailable Memory FWA. 


238 




EE 


KrBLOCK 


Size of Blocking Buffer in Words (180 or 512). 


239 




EF 


KrFEF 


FORTRAN Background Error Severity (1). 


240 




F0 


KrTVECT 


Pointer to Transfer Vector Table. 


241 




Fl 


K:FWA 


Legal TVECT Entries to FGD-FWA. 


242 




F2 


K : LWA 


Legal TVECT Entries to FBD-LWA+1. 


243 




F3 


F:FWA1 


TVECT FWA for T Register Check. 


244 




F4 


KrLWAl 


TVECT LWA+1 for T Register Check. 


245 




F5 


KrOLOAD 


Pointer to RBM OVrLOAD Table. 


246 




F6 


KtMTMP 


Size of Nondynamic Storage, in Words (6). 


247 




F7 


KrCCBUF 


Address of Control Card Buffer. 


248 




F8 


KrNRFQ 


Pointer to Nonresident Foreground Queue Table. 


249 




F9 


K:NEXT 


Next Available Sector in BT Area. 


250 




FA 


KrPROTCT 


Pointer to Protection Register Table. 


251 




FB 


KrPMDTBL 


Pointer to Postmortem Dump Table. 


These names are as defined in the RBM Monitor and are not system definitions. Any references to these locations by 
these names must be defined in the user program (e.g., K:IOCS EQU X'E2'). 


Relationships for Monitor Constants: 




1. 


(K:PLFWA) = LWA+1 of RBM. 


4. (K:BACKP)= LWA+1 of Nonresident Foreground. 


2. 


(K:RFFWA) = LWA+1 of Public Library. 


5. (K:BACKBG) = (KrBACKP) + 39. 


3. 


(KrNFFWA) = LWA+1 of Resident Foreground 


6. (KrCCBUF) = (KrUNAVBG) - 62. 
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APPENDIX C. RBM SYSTEM ABORT CODES 



The abort codes given in Table C-l are the standard abort 
codes output by the Monitor, Basic FORTRAN IV Compiler, 
Extended Symbol assembler, Utility Subsystem, and RAD 
Editor (see also supplementary control command diagnostics 
in Appendix D). 



OVERLAY LOADER ABORT CODES 

The abort codes given in Table C-2 will be output by Over- 
lay Loader which will then exit via a call to the RBM 
routine M:ABORT= 



LOADER I/O ABORT MESSAGE 

The I/O abort message has the following format, followed 
by the message "ABORT IO location": 

oplb device type and number diagnostic 

where 

oplb is the operational label of the device or file 
on which the error occurred. 

device type and number pertain to the operational 
label. 

diagnostic is an error diagnostic corresponding to 
an I/O completion code.* 



The following diagnostics may be used: 

UNRECOVERABLE I/O ERROR 

CALLING SEQUENCE ERROR 

INVALID OPERATIONAL LABEL 

OL =0, OR OPERAT MEANINGLESS 

ILLEGAL END OF FILE 

END OF TAPE 

INCORRECT RECORD LENGTH 

ILLEGAL BUFFERING 

WRITE PROTECTED 

BEGINNING OF TAPE 

ILLEGAL RAD SEQUENCE 

BLOCKING BUFFER UNAVAILABLE 

An example of the I/O abort message is given below: 
BI M9D0 END OF TAPE 
ABORT IO 3F4C 



See Table 10, "I/O Completion Codes", in Chapter 4. 



BI is the oplb. 



AQT 



is me aevsce name ana numc? 



END OF TAPE is the diagnostic. 
3F4C is the ABORT IO location. 



Table C-l. RBM Abort Codes 



Code 


Meaning 


AE 


Assignment error during loading; improper I/O assignment or invalid format. 


AI 


Irrecoverable I/O error on device assigned to operational label AI. 


BI 


Irrecoverable I/O error on BI device. 


BO 


Irrecoverable I/O error on BO device. 


CC 


Error in control cards or in sequence of job stack. 


CK 


Irrecoverable error while checkpointing. 


CS 


Checksum error from absolute or relocatable binary input. 
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Table C-l. RBM Abort Codes (cont. ) 



Code 


Meaning 


DE 


Debug not resident when requested. 


ER 


Operator-recognized error condition. 


ES 


FORTRAN library abort*. 


FC 


Illegal FORTRAN control card. 


FS 


FORTRAN abort*. 


FX 


A control card was encountered in the FORTRAN source deck. 


GO 


Irrecoverable error on output to the GO file when using a !REL command. 


HX 


Illegal hex parameter. 


IE 


Error in input deck. (Usually, a negative ORG item has been input. ) 


IO 


Irrecoverable I/O error. 


LO 


Irrecoverable I/O error on LO device. 


NP 


No patch area has been allocated. 


OP 


Operator abort, From unsolicited key-in. 


OV 


Problem with device assigned to operational label OV. (Normally, OV is assigned to the RAD. ) 


PE 


Parity error in background (perhaps attempting to read from unavailable memory). 


PO 


The patch area has overflowed. 


PU 


Number of argument greater than temporary storage in MrPUSH . 


PV 


Protection violation. 


RE 


RAD Editor abort*. 


RS 


Irrecoverable error during restart. 


SI 


Irrecoverable input error in SI device. 


SQ 


Sequence error in absolute or relocatable binary deck. 


TL 


Background program time limit exceeded. 


TS 


Temp stack overflow. 


TY 


Invalid load type in ABS deck. 


UT 


Utility subsystem abort . 


XE 


Fatal error in loading. 


XS 


Extended Symbol abort . 


Affer the 


abort code is output, the processor will exit via the RBM routine MrABORT. 


Notes: 1. 


The processing of the job stack is discontinued following any abort. If an ! ATTEND control command 
was in effect, the Monitor will enter an "idle" state. This will allow the operator to correct the pro- 
blem and restart the job. If not in "attend", the Job Control Processor will read commands until a !JOB 
or !FIN command is encountered. All control commands encountered prior to the ! JOB or !FIN com- 
mand will be logged in with an indication (">" wTl 1 precede the command) that they have been ignored. 


2. 


If integral IOP timeout occurs, RBM checks foreground mailbox X'C5' for a watchdog receiver. If a re- 
ceiver is specified, RBM branches to it; otherwise, RBM halts with the address of the interrupt in 
the accumulator. An integral IOP timeout indicates hardware difficulties. 
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Table C-2. Overlay Loader Abort Codes 



Code 



Meaning 



Al 
A2 
A3 
A4 
A5 
A6 
A8 
A9 
BB 
CM t 

CR 1 



DS 



tt 



tt 



EF 

IT 

LI 

L2' 

L3 

L4 
15 
L6 f 

L8 
LS 

On 



PL 
RL 
RS 



ri- 



ft 



tt 



tt 



These codes are frequently caused by insufficient 
RAD Device File Numbers at SYSGEN. 



Error in accessing the RBMSYM file. 

Error in accessing the LIBSYM file. 

Error in accessing the EBCDIC library file. 

Error in accessing the DEFREF library file. 

Error in accessing the MODIR library file. 

No blocking buffer is available for the RBMID file 

Error in accessing the TVECT file. 

Error in closing the RBMID file. 

Cannot use RS' op label because it is already used by Overlay Loader. 

A COMMON displacement or size larger than that stipulated on the IOLOAD command or in a start 
item was detected. (Background abort only. ) 

A non-COMMON item was relocated into COMMON. This condition only occurs when an actual 
data item is to be stored into COMMON. 

The same identifier was used to name two different segments. 

An illegal end-of-file was detected. 

An illegal item type was detected. 

The library files cannot be loaded because of incorrect construction of the library. 

Labeled COMMON data (subtype 2) is for a block outside the current segment. 

Tha numkor r\f I nka arl fOUW^M !n^!(>iot n I I i-»\A/<-ir> I a nar mr\rill\a nrtz noon ayr-aariaA ((•• "" ran t Ivy 

limited to 40). 

Block size prescribed (subtype 0) is greater than that already allocated. 

Labeled COMMON symbol is defined as a program symbol within the current path. 

Labeled COMMON data from a Library Module (root) is intended for a block allocated in the program 
section of the root. 

An external DEF was encountered with the same label as a prior labeled COMMON block. 

Library search overflow. The number of unique library definitions and references along a program path 
exceed 225. 

An Overlay Loader function that prevents proceeding has occurred. The number of the overlay in which 
the malfunction occurred is indicated by n. 

Overlay Loader was unable to write the Public Library, the LIBSYM, or the TVECT files onto the RAD. 

Root of excessive length. 

Overlay Loader unable to correctly read the RBMSYM file from the SD area. 

Klrtf onminh conmonfc ufpro r\\\r\rr\kaA fr*r fho fncU The conmpnfc nnrnmator r\f tV\a I f*) I OAD mmmnntA 

should be larger. 
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90 10 37F-l(3/72) 



Table C-2. Overlay Loader Abort Codes (cont.) 



Code 


Meaning 


SD 


Next segment of the Overlay Loader cannot be loaded. 


SE 


Input ROM had an error severity level greater than zero. 


SG* 


Format or parameter error was detected on a !$SEG command. 


SL 


The length of a segment was excessive, (see !$ROOT and !$SEG commands for maximum segment 




size). 


to" 


There was a table overflow. Decrease the size of the program or reduce the number of external 




symbols. 


UN" 


The number (on the !$SEG card) of the segment to which this one is attached has not been defined. 


Loading will continue until terminated but the load program file will not be generated and exit will be through 


MrABORT 




Loading 


will be terminated and, if a map has been requested, it will follow to the point of termination, after which 


the exit w 


ill be through MrABORT. 
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APPENDIX D. CONTROL COMMAND DIAGNOSTICS 



The following error messages may appear on the background 
DO device as a result of an error condition detected by the 
JCP. These diagnostics supplement the abort or attend error 
codes printed by the JCP. 



Message 

.BK OPLB/DFN TBL FULL 

.FG OPLB/DFN TBL FULL 

. ILL CrCODE 

.ILLCrTCB 

. ILL RAD SEQUENCE 

.INV COMMAND 



Comments/ 
Associated Commands 

ASSIGN, DEFINE, default 
assignments for system 
processors 

ASSIGN 

C: (Connect) 

C: (Connect) 

WEOF, REWIND, UNLOAD, 
FBACK, FSKIP, RBACK, RSKIP 

Command not recognized as 
a Monitor service command, 
system processor, or user 
processor. 



Message 



INV OPLB OR DFN 



INV OPTION 



NO 'FG' KEY-IN 



NO 'SY' KEY-IN 



Comments/ 
Associated Commands 

ASSIGN, DEFINE, WEOF, 
REWIND, UNLOAD, FBACK, 
FSKIP, RBACK, RSKIP 



An invalid option has been 
encountered on a Monitor 
service command 



ASSIGN, XEQ,C: 



WEOF, ABS, REL 



OP NOT MEANINGFUL WEOR, REWIND, UNLOAD, 

FBACK, FSKIP, RBACK, 
RSKIP 



RAD TEMP OVERFLOW DEFINE, default assignments 

for system processors 
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The following table should be used to determine the standard assignments for an installation's RBM operational labels and to determine which operational 
labels, if any, should be suppressed by being assigned to file 0. The RBM operational labels are defined under the ! ASSIGN command in Chapter 2. 



CO 



RBM^^s^Qperational 
and ^^N^Labels 
Processors ^v.. 


Device 
Number 1 


CC 


SI 


UI 


AI 


BI 


BO 


UO 


LL 


DO 


RBM 


Read/Wrire 
unsolicited 
key- in 


Read 

Control 

Commands 






Read 

Absolute 

Binary 


Read Object 
modules with 
! REL command 






Write Control 

Command 

Images 




XSYMBOL 




[Read Control 
commandsj 


Read Source 
Statements 








Write Reloc. 
Binary 




Used for CC 
Diagnostics 


Write XSYMBOL 
Error Messages** 


Concordance 






Read Source 
Statements 














Write Concordance 
Error Messages** 


Basic FORTRAN IV or 
ANS FORTRAN IV 






Read Source 
Statements 








Write Reloc. 
Binary 








Math Library 




















Write Library 
Error Messages 


Overlay Loader 




Read 

Control 

Commands 
















Write Map, Loader 
Error Messages and 
Control Command 
Images 


RAD Editor 




Read 

Control 

Commands 








Object Module 
Input to System 
and User 
Libraries 


Output Copies of Ob- 
ject Modules from Sys- 
tem and User Libraries 






Write Error Mes- 
sages, Control 
Commands and 
operator key-ins 


Utility Executive 




Read 


Read 

Control 

Commands 














Write Utility Error 
Message and Con- 
trol Command 
Images** 


Utility Copy* 






Read Control 
Commands 


Read 
Input 














Utility RECEDIT 






Read Control 
Commands and 
Modific Input 


Read 
Input 








Write 
Output 






Utility OMEDIT 






Read Control 
Commands 


Read 
Input 




Read Binary 
Modific. Input 




Write 
Output 






Utility DUMP 






Read Control 
Commands 


Read 
Input 














Utility SEQEDIT 






Read Update 
Data 


Read 
Input 








Write 
Output 






May use any op label for output. 
Suppressed if assigned to same device as LO. 






CO 

ISA 

CO 

3D 
00 



30 



00 



GO 

en 



St 



> 

-a 

Q. 



^"v^RBM 
RBM ^^Operational 
and ^ s v N Labels 
Processors ^v^ 


LO 


LI 


PM 


OC 


XI 


PI 


OV 


X2 


X3 


S2 


GO 


X4 


X5 


RBM 






Write Abso- 
lute Binary 
Monitor (SYS- 
GEN only) 


Write Proces- 
sor and Mon- 
itor Abort 
Messages 




Read RBM 
Overlays 


Write Pro- 
gram Loaded 
by IABS 
Command 








Write Ob- 
ject Mod- 
ule with 
!REL 
command 






XSYMBOL 


WRITE Listing 
Output and 
XSYMBOL 
Error Messages 






Operator 
Commu- 
nications 


Intermediate 
Output 


Read 

XSYMBOL , 
Overlays 




Output 

Encoded 

Text 


Output 
Program 
Locals 


Output 
Standard 
Proce- 
dures 


Output 
Execution 
Object 
Language 






Concordance 


Write Listing 
Output and 
Concordance 
Error Messages 


























Basic FORTRAN IV or 
ANS FORTRAN IV 


Write Listing 
Output and 
FORTRAN 
Error Messages 








Intermediate 
Output 


Read 

FORTRAN 

Overlays 










Output 
Execution 
Object 
Language 






Math Library 


Write Library 
Error Messages 






Operator 
Commu- 
nications 




















Overlay Loader 




Read Reloc. 
Binary 
Library File 




Operator 
Commu- 
nications 


Contains Sym- 
bol Table for 
each segment 


Read 

OLOAD 

Overlays 


Write 
Core 
Images 


Read 
MODIR 
File ' 






Read 

Reloc. 

Binary 






RAD Editor 


Write Maps 
and Dumps 
of Files 






Operator 
Commu- 
nications 


Replace Files 
and Maintain 
Libraries 


Read RAD 

Editor 

Overlays 




Replace 
Files and 
Maintain 
Libraries 


Maintain Li- 
braries and 
Update Di- 
rectories 






Maintain 
Libraries 




Utility Executive 


Write Utility 
Error Messages, 
Control Com- 
mand Imoges and 
other Output 






Operator 
Commu- 
nications 




Read 

Utility 

Overlays 














Prestore 
Commands 
From SI 


Utility Copy 
























Input 

for 

Verify 




Utility RECEDIT 


Write Modi- 
fication Log 


























Utility OMEDIT 


Write Module Log 
















Prestore Bl 










Utility DUMP 


Write Dump 


























Utility SEQEDIT 


Write Listing 



























APPENDIX F. CHARACTER-ORIENTED COMMUNICATIONS (COC) EQUIPMENT HANDLER 



This appendix describes the interface of RBM with the Xerox 
character-oriented communications (COC) equipment. * The 
COC equipment provides communication between Sigma 2/3 
real-time programs and various terminal devices. The COC 
consists of a controller and from one to eight attached line 
interface units, with each unit containing from one to eight 
send-and-receive modules. The Sigma 2/3 RBM can accom- 
modate one COC, which gives the user up to 64 lines each 
with send-and-receive equipment. The terminal devices 
supported (one per line) can be Teletype Models 33, 35, 
or 37. Other terminals can be connected but they must use 
ANSCII control codes, and all editing must be done by the 
user program. 

The computer requirements for use with the COC equipment 
are as follows: 



3. A real-time task connected to the output interrupt of 
the communications controller, which transmits out- 
put messages and editing characters at end-of-message 
(EOM). 

4. Conversion tables (ANSCII to EBCDIC, and vice 
versa). 

5. An input buffer (overlays the initialization routine). 

During initialization of RCOC, lines are tested for installed 
send and/or receive modules, and receive modules are given 
a turn-on test. Should a line have neither module instatted 
or has a receive module that will not turn on, the message 

TROUBLE LINE 



1. RBM with at least 16K of core memory. 

2. One buffered input/output channel dedicated to the 
COC controller. 

3. Two external interrupts dedicated to the COC 
controller. 

4. External interface feature. 



will be written. 

RCOC must be assembled separately for each installation 
unless the default cases for the installation specific assem- 
bly parameters agree with the parameters desired. The 
assembly parameters are as follows: 

1 . The device number of the COC (buffered input/output 
(default = 7). 



DESCRIPTION OF COC PACKAGE 

The COC software package allows messages to be communi- 
cated via the character-oriented equipment, and consists 
of two sections — M:COC and RCOC. 



M'.COC M:COC is a Monitor service routine that initi- 

ates all read, write, and control operations. It is part of 
the RBM overlays and requires no modification by the user 
before use. (M:COC is described in detail in Chapter 4.) 



RCOC RCOC consists of the following tasks and tables 

that make up a resident foreground program: 

1. An initialization routine. 

2. A real-time task connected to the input interrupt of 
the communications controller, which edits and trans- 
lates input characters, echoes the characters if re- 
quired and forms input messages. 



2. The COC number (direct input/output) (default =0). 

3. The input interrupt level (even number of the even-odd 
pair (default = 110). The output interrupt level is 
assumed to be the odd number. 

4. Number of lines used (n), where all line numbers to 
n-1 are assumed to be used (default = 1). 

5. An option parameter that may be set to include code 
for processing the display device terminal, 7550/55. 



COC OPERATION 

RCOC is a resident foreground program and must reside on 
either the SP or UP area of the RAD. It is read into core 
memory and operated whenever RBM is rebooted. The 
RCOC initialization routine turns on all transmitters and 
receivers, arms and enables the input and output interrupts, 
initiates input from the COC controller into a wraparound 
buffer, and exits. At this point, all lines are set to the 
"disconnected" status, ready to be connected and used by 
the real-time programs. 



See Xerox Sigma Character-Oriented Communications 
Equipment Reference Manual, Publication 90 09 81, for a 
description of the equipment involved, the possible con- 
figurations, and the various uses for the equipment. 



All line-control and read-or-write operations are initiated 
by calls to M:COC. A request to read merely causes the 
line status to be set to "read", which in turn causes the 
input interrupt routine to accept input from that line and 
build the input message in the user's buffer. A request to 
write causes M:COC to turn on the transmitter and transmit 
the first character in the user's buffer. Thereafter, an output 
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interrupt is generated once each "output word time" (i.e., 
once each time the transmitter can transmit). The output 
interrupt routine transmits characters from the user's buffer 
until the entire message is sent and then turns off the 
transmitter. 

As each input or output message is completed, the status of 
the line is set to "message complete" and an EOM Receiver 
(if present) is operated at the input or output interrupt level. 
The receiver should trigger the requesting task and return to 
the location contained in the L register. 



AUTOMATIC DIALING 

If the Automatic Dialing Equipment (ADE) is included, 
real-time tasks can dial a terminal and connect it to a 
predetermined COC iine. The ADE is a muitiunit con- 
troller that controls up to 16 dial positions. It requires a 
dedicated buffered IOP channel. 

The dialing operation can be accomplished via M:IOEX. 
A TDV should first be performed to ensure that the dial posi' 
tion is available. Then an SIO can be issued to activate 
the ADE and address the dial position. Any order byte will 
be interpreted as a "write". The memory buffer contains 



the number of the data set being dialed (two bytes per word; 
each digit occupies the rightmost four bits of the byte in 
four-bit BCD). After the dialing procedure has been com- 
pleted, the task should check the status of the COC line 
before attempting to send or write on it. 



RESTRICTIONS 

The priority of the input/output interrupt pair must be 
higher than any program using its services via MtCOC 
and should also be higher than other real-time programs 
with long execution times. If a program with a higher 
interrupt priority runs for a long period of time, the in- 
put buffer may become filled and data may become lost. 
The output data would be delayed but no data would be 
lost. 

All COC lines (i.e., assembly parameters) are assumed to 
be operational. The RCOC initialization routine will 
loop, attempting to turn the receiver on for a nonexistent 
COC line number. 

If automatic dialing is included, the user must include 
M:IOEX during SYSGEN and must input the dialing posi- 
tions as XX type devices. 
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APPENDIX G. SYSGEN AND ASSEMBLY TIME OPTIONS 



The optional RBM capabilities below are obtainable as a 
package in response to the SYSGEN query INC. MISC. 
At least 100 (decimal) additional resident core memory 
locations are required. 



HEXADECIMAL CORRECTOR CARDS 

Patches may be loaded at execution time for either the 
Monitor itself or any user program. All corrector cards 
have the form 

aaaa cccc 1 fcccc^. . .cccc ] [*comments] 



aaaa is the first (or only absolute core memory 

location to be modified. 

cccc- are the desired (hexadecimal) contents of 

aaaa and the following n-1 locations. 



Patches may be loaded dynamically to user program or the 
Monitor in either of two ways: 

1. Following a HEX control command. 

2. Following an unconditional H key-in. 



Note: Patches at boot time will be written 
to the RAD. At other times, 3 cells 
of the RBM Patch Area are needed for 
each patch. The overlay is also ex- 
panded to its physical limits. 

Any value on a corrector card preceded by an R; that 
is, Recce-, will have the bias added to it. Any value 
on a corrector card preceded by a P; that is, Pcccc., 
will have the bias of the RBM Patch Area added to it. 

The programmer must not use the first and last cells of 
the Patch Area, as the first contains the length of the 
Patch Area, and the last contains the number of tem- 
porary RBM overlay patches. As mentioned previously, 
three words of the Patch Area are needed for each patch. 
These are taken from the top of the Patch Area down- 
ward, thus a user with a large Patch Area need be con- 
cerned only with the first word. 

To patch program segments, Data Switch must be placed 
in the "1" state. This causes the RBM to type "BEGIN 
SEB xx " (where xx is the segment number; XX = for the 
root) and go into an idle state after each segment is loaded. 
Correctors can then be loaded to the segment following an 
H key-in. An S key-in will cause RBM to resume operation. 
The ability to type the message "BEGIN SEG xx" is deter- 
mined when RBM is assembled and is not related to the in- 
clusion of the "MISC. " routines. 



Patches to the Monitor may be loaded at boot time if Data 
switch 1 is set (see Chapter 11). These patches will also 
be written to the RAD, thus ensuring a permanent change 
to all future boots. 

All corrector decks are terminated by an EOD control com- 
mand. To patch relocatable programs, a bias card may be 
used. Its form is 



bbbb 
fPAl 

Lid Ixx J 



/her 



bbbb is the bias and the following correctors are 

loaded relative to that location. 

PA means that the following corrections will 
be loaded relative the RBM Patch Area (see 
Figure 13). 

xx is an RBM overlay ID as described in 

Chapter 11; thus the corrections following 
the bias card are loaded relative to the 
overlay base. 



THREE-CHARACTER PROCESSOR SEARCH 

An assembly time option exists for the Job Control Processor 
(which does not increase resident RBM) to identify a pro- 
cessor from the first three characters input. 

When the Control Command Interpreter encounters a pro- 
cessor request such as IXSYMBOL, a search is first made 
of the system, then the user processor area, to locate the 
file whose name matches the requested processor exactly. 
Normally, if this search fails, the Monitor aborts the job. 
However, if this assembler option has been selected, the 
request is then truncated to three characters (i.e., !XSY) 
and the search of the system and user processor areas is 
repeated. Thus, if Extended Symbol has been defined on 
the system processor area of RAD as the three -character 
name !XSY, either a request of IXSYMBOL or !XSY will 
locate the system processor. 



An optional assembly parameter in the RBM subtask 
S:LOAD. This parameter does not increase RBM. 
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APPENDIX H. MEMORY REQUIREMENTS 



CORE SPACE REQUIREMENTS FOR RBM 

The minimum RBM system (which would consist of keyboard/ 
printer, paper tape, and RAD I/O routines, and a minimum 
number of RAD device-files and operational labels) requires 
about 4300-jq cells for the Real-Time Batch Monitor and all 
its tabies. This minimum core space requirement will in- 
crease as handlers are added for additional peripherals, 
as additional optional software routines are chosen (see 
Table H-l) during SYSGEN, and as additional device- 
files, operational labels, or Pubiic Library DEFs are allo- 
cated during SYSGEN, The following table indicates the 
approximate core space requirements for the additional rou- 
tines. Unless otherwise indicated, these number are only 
approximate and have been rounded to the next higher 
multiple of 25. 



Table H-l. Core Requirements for Additional Software 



Handler or routine 


Approximate 
size (decimal) 


Multiply/Divide Simulation 
Software 


173 


Power Off/On 


293 


M:IOEX 


198 


Job Accounting 


216 


Line Printer Handler 


62 


Card Reader Handler 


2 (exact size) 


BCD Option for Card 
Reader 


2 (exact size) 


Magnetic Tape Handler 


95 


Card Punch Handler 


8 (exact size) 


BCD Option for Card 
Punch 


2 (exact size) 


Each additional RAD Device 
File 


15 (exact size) 


Each additional Operational 
Label 


2 (exact size) 


Each Public Library DEF 


2 (exact size) 



must allocate at least 3800 cells for background to accom- 
modate the RBM Job Control Processor which executes in the 
background space. 

CORE SPACE REQUIREMENTS FOR THE 
RBM PROCESSORS 

The minimum background space necessary to individually 
load with the Overlay Loader program and to execute all 
the RBM Processors is 7K cells (IK = i024]o). The largest 
processor here is Basic FORTRAN IV, which requires 7K 
cells when it'is loaded by the Overlay Loader. FORTRAN 
programs of reasonable size can be compiled in 7K of back- 
ground. Extended Symbol can be loaded in a minimum of 
6.25K of background, and a program of approximately 1200 
to 1800 instructions could be assembled in this minimum 
space. The other RBM processors can all be loaded and 
executed in less than 6K of background. 



RAD SPACE REQUIREMENTS 

Table H-2 gives the allocations for the system areas of the 
RAD, if a user chooses not to override the default case. The 
following discussion assumes a 360-byte-per-sector RAD. 



Table H 


-2. RAD Syst 


em Area Requirements 


Area 


Size 


Comments 


Checkpoint 


n sectors 


n=size of background 
(in sectors). 


System 
Processor 


31 tracks 


Sufficient to contain all 
RBM processors plus RBM. 


System 
Library 


9 tracks 


Sufficient to contain two 
versions (extended and 
basic) of Math/Run-Time 
Library. 


System 
Data 


15 tracks 


RBM files. 



Hence, the resident core space requirements for RBM vary 
from 4300 to 6200 cells, depending upon the user's con- 
figuration. If background processing is desired, the user 



Note that this leaves approximately one spare track in the 
system data area. However, if a Public Library is included, 
the file LIBSYM must be added to the system data area. 
Hence, the system areas and the checkpoint area will 
normally consume about 45 tracks of the RAD. (The small- 
est Xerox RAD, .75 megabyte, has 128 tracks.) The only 
other area used by the system is the background temp area. 
The processor that normally requires the largest background 
temp area is Extended Symbol. Extended Symbol normally 
requires the background temp area to be split into three 
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90 10 37F-l(3/72) 



scratch files, called XI, X2, and X3.* File XI is a 
compressed file and contains the user's source deck 
(about 12 source cards can be compressed into one RAD 
sector). File X2 contains the user's source deck in an en- 
coded form (normally about 36 source cards can be stored 
in one RAD sector on X2). File X3 is only used if the pro- 
gram being assembled contains local symbols. Normally, 
the RAD space required for X3 is insignificant compared 
with XT and X2. Hence, to assemble a 5000-card source 
program, approximately 35 tracks of background temp area 
would be required. Thus, if a user wants to have all the 
system processors and a complete system library stored on 
the RAD, and wants to allocate enough background temp 



area to assemble about a 5000-line source program, approxi- 
mately 80 tracks of the RAD would be used. 



The Job Control Processor will automatically divide the 
total background temp area into three scratch files upon 
encountering an IXSYMBOL command. The total area is 
divided amoung the XT, X2, and X3 files according to the 
following ratios: 

X1:X2:X3 =30:10:1 

The user can override these default allocations by inputting 
a {DEFINE command prior to the IXSYMBOL command. 
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APPENDIX I. CALCULATING THE RBM SIZE 



To calculate the size of RBM (RBM LWA) before a SYSGEN, 
add the base value of F86 or 3980: 

8 x number of I/O channels 

2 x number of definitions in the Public Library 

4 x number of entries in nonresident foreground 
queue 

4 x number of Master Dictionary entries 

10 x number of RAD'/aisk fxick devices 



To this figure add the following: 

125,.,. or 293,. . cells if aYresponse to INC. POWER 
ON/OFF 

AD,.„ or 173,. n > cells if a Y response to INC. MUL/ 
DIV SIM. 

C4 n . or 198,. Q . cells if a Y response to INC. M:IOEX 



D8 



.... or 216,.... cells if a Y response to INC. CLOCK 



ONE 



10 n ,. or 16 nm cells if a Y response to INC. DEBUG 

56/wv or 85,._. cells if a Y response to INC. MISC. 
(10) (IU) 

2 or 2,._> cells if a Y response to INC. C. O.C. 



Add to this amount the number given below (see Table 1-1) 
if the corresponding device type is included in the SYSGEN 
parameter DEVICE FILE INFO: 

To this sum, add two cells for each background or foreground 
operational label. 

Since SYSGEN attempts to store whatever optional routine 
of tables it can into the unused interrupt locations, the size 
of the unused interrupt region can generally be subtracted 
from this accumulated sum. The size of this area can be 
determined by subtracting the value input for the SYSGEN 
parameter MAX. INT. LOC from 18F(i$) (399(] ))- How- 
ever, this figure will be less than the true size of RBM since 
not all of these unused interrupt locations can be used 



Table 1-1. Device Type Table Allocations 



Device 


Size 


First Input 


Additional Inputs 


Hex. 


Dec. 


Hex. 


Dec. 


KP 
Lp2 ttt 

LP8 

CR4 

CP1 

CP3 m 

Any magnetic tape 

PT 

PL 

RD" 

XX 


21 
25 
59 
IE 
IE 
9F 
9E 
27 
IB 

7 


33 (required) 

37 

89 

30 

30 
159 
158 

33 

27 

7 


10 
F 
C 
C 
10 
87 
D 
10 
C 
15 
7 


16 
15 
12 
12 
16 
135 
13 
16 
12 
21 
7 


Add two cells to the first input if magnetic tape is BCD and add 2 cells if 9-track magnetic tape. 
The default case for background is nine RD files. Add lOOlO cells if any disk pack device is defined. 
If both LP2 and CP3 are used, subtract 6 from total. 



170 Appendix I 



APPENDIX J. DEBUG EXPANSION OF INSTRUCTIONS 



EXPANSION OF INSERTED INSTRUCTIONS 



EXPANSION OF MOVED INSTRUCTIONS 



Class 1 instructions that are inserted via the insert (I) com- 
mand are expanded into more than one instruction if desig- 
nated in the op*address form. (Note that expansions of 
indirect instructions are not reentrant. ) 



An instruction that is moved from the point of insertion to 
the insert block will require expansion if its addressing is 
relative or if it is a register copy instruction in which the 
P register is the source. 



Op is 


direct (0): 


op 


*$ + 2 






B 


$ + 2 






DATA 


address 


Op is 


indexed (2): 


op 


*$ + 2, 1 






B 


$ + 2 






DATA 


address 


Op is 


indirect (4): 


STA 


$ + 6 






LDA 


*$ + 7 






STA 


$+5 






LDA 


$ + 3 






op 


*$ + 3 






B 


$ + 4 






DATA 









DATA 









DATA 


address 


Op is 


indirect and 


indexed (6): 






STA 


$+6 






LDA 


*$ + 7 






STA 


$+5 






LDA 


$+3 






op 


*$ + 3, 1 






B 


$+4 






DATA 









DATA 









DATA 


address 



Class 2 instructions are expanded as follows: 



op 
B 
B 
DATA 



$ + 2 
$+3 
*$+ 1 
address 



The relative instructions are expanded the same as the 
inserted instructions discussed in the first part of this 
appendix. In the case of Insert Before (IB) or snap- 
shots, register copy instructions in which P is the source 
and the clear bit is set will be expanded in one of two 
ways: 

1. If the destination is the A register: 



LDA 
op 
B 
DATA 



$ + 3 
A, A 

$ + 2 
a+ 1 



2. If the destination is not the A register: 



STA 

LDA 

op 

LDA 

B 

DATA 

DATA 



$+5 
$ +5 
A,R 

$ + 2 
$ + 3 

a+ 1 



In the above expansions, a is the location (point) of the 
insertion and op has the appropriate settings for the incre- 
mentation and inversion bits. 

Debug has no facility for expanding a copy instruction where 
either (I) the P register is the source, the A register is the 
destination, and the clear bit is reset, or (2) the P register 
is the destination and the clear bit is reset. In this case a 
Debug syntax error is generated. 
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APPENDIX K. DEBUG INSERTION STRUCTURE 



An insert-ion at location awill result in the following: 
a B */3 

B DATA X 



r< 



moved instruction expansion if IA command 



inserted instructions or snapshot call code 



moved instruction expansion if IB or snapshot command 



B *$ + l 

L DATA a+ 1 



where & is one of the Debug cells in the zero table and Y is an area in the insertion block. 
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APPENDIX L DEBUG SNAPSHOT CALLING SEQUENCE 



A snapshot inserted at location a will generate the foil owing 
calling sequence (which is inserted in the insertion block 
similar to a Debug IB command): 



a] 
entry 



DATA D:SNAP 

DATA block 

instruction that was at location Ct 

WD X'FC (foreground only) 

STA *a2 

RCPYI P,A 

B *al 



DATA 


a 


DATA 


key 


conditions if any 




DATA 


-1 


message if any 




DATA 


-1 


dumps if any 




DATA 


-1 


expanded instruction 


from location a 


B 


*$ + 1 


DATA 


a+ 1 



where 



block is the address of the first word of the inser- 

tion block and is used to save the A register. 

key (bits 0-2) designates type of snapshot: setting 
bit designates stepping snapshot; setting bit 1 
designates line printer snapshot output; and setting 
bit 2 designates keyboard control requested. 



message 
any. 



is the string of EBCDIC characters, if 



condition is a string of relational expressions sep- 

arated by logical operators. A relational expres- 
sion occupies three words as follows: 



loc, reg, or constant 


Ml 


M2 




C 


E 


L 


G 


loc, reg, or constant 



dumps 



where 

Ml (bits 0-1) designates the type of 
quantity in the first word: 

00 location 

01 register 
10 constant 

M2 (bits 2-3) designates the type of 
quantity in the third word. 

C (bit 12) designates comparison where 
= arithmetic and 1 = logical. 

E (bit 12) designates equal comparison. 

L (bit 14) designates less than comparison. 

G (bit 15) designates greater than 
comparison. 

A logical operator occupies one word: 

logical or 

1 logical and 

are two-word or three-word items: 

register dump 



1 


T 




register number 


or 





T 




loc 1 


loc2 



memory dump 



where 

T = 1 designates keyboard/printer and 

line printer output. 

T = designates line printer output. 
A zero register number designates all registers. 
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Note: For each entry in this index, the number of the most significant page is listed first. Any pages thereafter are listed in 
numerical sequence. 



abort codes, 158 

ABS control command (Monitor), 9 

accounting and elapsed time, 4 

ADD control command, 90 

AIO Receivers, 71 

allocation 

core memory, 123 

file control table (FCT), 127 

RAD, 123 

SYSGEN initial core, 122 
ASSIGN control command (Monitor), 10 
ASSIGN control command (Utility), 102 
ATTEND control command (Monitor), 12 
automatic dialing, 166 



B 



B (branch) Debug command, 145 

background, 7,2 

background core allocation example, 125 

background task, 8 

Basic FORTRAN IV, 6 

binary object record format, 147 

BLOCK control command, 80 

branching to service routines, 27 



C (debug input device) Debug control, 145 

C: control command (Monitor), 12 

calculating RBM size, 170 

calling COPY, 103 

calling DUMP, 105 

calling Object Module Editor, 106 

calling Overlay Loader, 79 

calling RAD Editor, 90 

calling Record Editor, 108 

calling Sequence Editor, 110 

calling Utility, 100 

card punch, write to, 40 

card reader, special editing, 36 

CC control command (Monitor), 13 

CHANGE control command, 109 

Character-Oriented Communications (COC) equipment 

handler, 165 
Character-Oriented Communications (COC) handler, 7 
checkpoint, 4 

checkpointing background, 73 
CLEAR control command, 94 
compressed RAD files, 8 



computing library file sizes, 88 

Concordance, 6 

control command diagnostics, 162 

control command, Basic FORTRAN IV format, II 

control command, Extended Symbol format, 17 

control commands, Monitor, 9-16 

control commands, Processor, 16-18 

control commands, Utility, 101 

control panel task, 65 

COPY control command, 104 

COPY error messages, 114 

COPY operating characteristics, 103 

COPY operational labels, 103 

COPY routine, 102 

core layout after absolute load, 126 

core layout after SYSGEN and SYSLOAD, 126 

core layout, Overlay Loader, 76 

core memory allocation, 123 

core memory allocation example, 124 

core space requirements, 168 



D (define) Debug command, 142 

data files, 4 

data files, RAD, 88 

Debug commands, 142 

B, 145 

C, 145 
' D, 142 

E, 145 

I, 143 

K, 145 

M, 145 

P, 145 

Q, 145 

R, 144 

S, 143 

T, 144 

X, 144 
Debug control, 141 
Debug error messages, 146 
Debug expansion of instructions, 171 
Debug insertion structure, 172 
Debug processor, 141-146, 6 
Debug snapshot calling sequence, 173 
DEFINE control command (Monitor), 13 
DELETE control command (RAD Editor), 91 
DELETE control command (Utility), 108,110 
description of object modules, 147 
device type table allocations, 170 
LTV-un conrrwi cumffiunu, 7Z. 

DUMP control command (RAD Editor), 93 
DUMP control command (Utility), 105 
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DUMP operating characteristics, 105 
DUMP operational labels, 105 
DUMP routine, 104 



H 



hardware requirements, 5 

HEX control command (Monitor), 14 

hexadecimal corrector cards, 167 



E 



E (exit from interrupt level) Debug command, 145 

editing operations, M:COC, 57 

END control command (Overlay Loader), 85 

END control command (RAD Editor), 96 

END control command (Utility), 102 

EOD control command (Monitor), 13 

EXCLUDE control command, 83 

Extended Symbol, 6 



F 



FBACK control command (Monitor), 13 

FBACK control command (Utility), 101 

FCOPY control command, 92 

File Control Table (FCT) allocation, 127 

file name, 4 

files, computing library size, 88 

files, data, RAD, 88 

files, GO and OV, 18 

files, library, RAD, 88 

files, random RAD, 61 

files, sequential RAD, 60 

files, special editing random-access, RAD, 37 

files, special editing sequential, RAD, 37 

files, write on, 40 

files, write on random-access, RAD, 41 

FIN control command (Monitor), 13 

floating accumulator, 8 

foreground, 7,2 

foreground initialization, 68 

foreground priority levels, 67 

foreground priority levels and I/O priority, 71 

foreground programs, 63 

foreground user's Debug capability, 141 

FORTRAN control command (Processor), 18 

FSKIP control command (Monitor), 13 

FSKIP control command (Utility), 101 



I 



I (insert) Debug command, 142 

I/O completion codes, 35 

I/O end action, 59 

I/O initiation, 59 

I/O operations, 59-62 

I/O recovery procedure, 20 

IDENT control command, 110 

INCLUDE control command, 83 

initial loading of system processors, 137 

INITIALIZE control command, 95 

input/output task, 65 

INSERT control command 107, 109 



J 



fob, 8 

JOB control command (Monitor), 14 

Job Control Processor (JCP), 9 

fob step, 8 

JOBC control command (Monitor), 14 



GDTRACK control command, 94 
GO and OV files, 18 



K (keyboard/printer) Debug command, 145 
key-ins, 24 

BL, 24 

BR, 24 

C:, 24 

CC, 24 

CP, 24 

D, 25 

DB, 24 

DE, 24 

DF, 25 
DM, 25 
DR, 25 
F, 25 
FG, 25 
FL, 25 
FR, 25 
H, 25 
KP, 25 
M, 25 
Q, 26 
R, 26 
S, 26 



Index 
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SY, 26 

T, 26 

UL, 26 

W, 26 

X, 26 

Z, 26 
keyboard/printer, special editing, 36 
keyboard/printer, write, 39 



L 



LADD control command, 92 

language translators, 6 

LB control command, 83 

LCOPY control command, 92 

LD control command, 82 

LDELETE control command, 92 

LIB control command, 81 

library files, 4 

library files, RAD, 88 

LIMIT control command (Monitor), 14 

line printer, write to, 39 

LIST control command, 107, 108 

LMAP control command, 93 

load item format, 148 

Loader error messages, 85 

Loader I/O abort message, 158 

loading foreground programs, 66 

loading nonresident foreground programs, 68 

loading RBM part-2, 136 

loading resident foreground programs, 66 

logical/physical device equivalence, 60 

Long (load) map format, 77 

LREPLACE control command, 92 

LSQUEEZE control command, 92 



M 



M (modify memory) Debug command, 145 

MrABORT, 43 

MrASSIGN, 50 

MrCKREST, 45 

MrCLOSE, 47 

M:COC, 55 

M:COC restrictions, 166 

M:COC service routine, 165 

MrCTRL, 41 

MrDATIME, 42 

MrDEFINE, 49 

MrDKEYS, 48 

M:DOW, 54 

MrEXIT, 44 

K^j-jCYlKI 44 

MrlNHEX, 45 
M:IOEX, 27 
MrLOAD, 46 



MrOPEN, 47 
MrOPFILE, 53 
M:POP, 53 
MrREAD, 31 
M:RES, 52 
M.-RSVP, 53 
MrSAVE, 44 
MrSEGLD, 48 
MrTERM, 43 
MrWAIT, 48 
M.-WRITE, 37 
machine fault task, 64 
magnetic tape, special editing, 37 
map, 77 

MAP control command, 93 
MD control command, 83 

memory requirement and insertion block definition, 141 
memory requirements, 168 
MESSAGE control command (Monitor), 14 
MESSAGE control command (RAD Editor), 95 
MESSAGE control command (Utility), 101 
messages to the operator, 133 
messages, COPY error, 114 
messages, Debug error, 146 
messages, Loader error, 75 
messages, Monitor, 20 
messages, OMEDIT error, 1 15 
messages, RAD Editor, 96 
messages, RAD Editor warning, 98 
messages, RECEDIT error, 115 
messages, SEQEDIT error, 116 
messages, Utility control function, 112 
messages, Utility I/O error, 111 
ML control command, 81 
MODIFY control command, 107,108 
Monitor constants, 156 
Monitor control commands, 9 
ABS, 9 

10 

12 



13 



ASSIGN, 
ATTEND, 
C:, 12 
CC, 13 
DEFINE, 
EOD, 13 
FBACK, 13 
FIN, 13 
FSKIP, 13 
HEX, 14 
JOB, 14 
JOBC, 14 
LIMIT, 14 
MESSAGE, 
PAUSE, 14 
PMD, 14 
PURGE, 15 
RBACK, 13 
REL, 15 
REWIND, 15 
RSKIP, 13 
TEMP, 16 



14 
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UNLOAD, 16 

WEOF, 16 

XEQ, 16 

XED, 16 
Monitor messages, 20 
Monitor service routines, 27-58,8 
Monitor tasks, 63 
Monitor zero table, 154 
MP control command, 81 
MS control command, 81 
multiply/divide exception tasks, 65 



N 

nonresident foreground, 8 

nonresident foreground creation or updating, 138 
nonresident foreground programs, 63 
nonresident foreground programs, loading, 68 
nonresident section, 1 



Object Module Editor control commands, 107 

Object Module Editor error messages, 115 

Object Module Editor operational labels, 105 

Object Module Editor routine, 105 

Object Module Editor operating characteristics, 106 

OLOAD control command (Overlay), 79 

operational labels, 10 

operational label usage, 163 

operator communication, 20-26 

operator control, 23 

OPLBS control command, 103 

overlay capabilities, 4 

overlay cluster configuration, 76 

overlay cluster organization, 74 

Overlay control commands, 80 

BLOCK, 80 

END, 85 

INCLUDE, 83 

LB, 83 

LCOM, 84 

LD, 82 

LIB, 81 

MD, 83 

ML, 81 

MP, 81 

MS, 81 

PUB LIB, 84 

RES, 84 

ROOT, 82 

SEG, 84 

TCB, 81 
Overlay Loader, 74-86,6 
Overlay Loader abort codes, 160 



Overlay Loader operational labels, 76 
overlay structure example, 75 



P (selective dumps) Debug commands, 145 

paper tape, special editing, 36 

paper tape, write to, 39 

patches (see PA option), 134 

PAUSE control command (Monitor), 14 

PAUSE control command (RAD Editor), 95 

PAUSE control command (Utility), 101 

PMD control command (Monitor), 14 

Power Off Task, 64 

Power On Task, 63 

preparing the program deck, 117-121 

PRESTORE control command, 102 

procedures, I/O recovery, 20 

Processor control commands, 16 

Processor files, 4 

Processor, system (and library creation), 139 

Processors, initial loading of system, 137 

program, 7 

Protection Violation Task, 64 

PUBLIB control command, 84 

Public Library, 4 

Public Library creation or updating, 138 

PURGE control command (Monitor), 15 



Q (quit) Debug command, 145 



R (remove snapshot or insertion) Debug command, 142 

RAD allocation, 123,62 

RAD area mnemonics, 12 

RAD Editor, 87-98,6 

RAD Editor control commands, 90 

ADD, 90 

BDTRACK, 94 

CLEAR, 94 

DELETE, 91 

DUMP, 93 

END, 96 

FCOPY, 92 

GDTRACK, 94 

INITIALIZE, 95 

LADD, 92 

LCOPY, 92 

LDELETE, 92 

LMAP, 93 

LREPLACE, 92 
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LSQUEEZE, 92 

MAP, 93 

MESSAGE, 95 

PAUSE, 95 

RESTORE, 94 

SAVE, 93 

SQUEEZE, 94 

TRUNCATE, 95 
RAD Editor messages, 96 
RAD Editor operational labels, 89 
RAD Editor warning messages, 98 
RAD file management, 62 
RAD files, 60 

RAD space requirements, 168 
RAD/disk areas, 3 

RAD/disk pack area organization, 87 
RADEDIT control command, 90 
random access RAD files, write on, 41 
random files, 61 

random-access RAD files, special editing, 37 
RBACK control command (Monitor), 13 
RBACK control command (Utility), 102 
RBM abort codes, 158 
RBM and foreground user's interface, 141 
RBM characteristics, 1 
RBM Control Task, 8,65 
RBM subsystems, 6 
RBM system processors, 17 
RBM/processor interface, 18 
RCOC, 165 

RCOC initialization routine, 58 
read automatic, 36 
read binary, 36 

read binary from keyboard/printer, 37 
read binary from paper tape, 37 
real-time priority, MrREAD, 36 
real-time programming, 63-73 
rebooting the system from RAD, 139 
Record Editor error messages, 115 
Record Editor operating characteristics, 107 
Record Editor operational label, 107 
Record Editor routine, 107 
record header format, 148 
reentrant routines, 4 
REL control command (Monitor), 15 
RES control command, 84 
resident foreground creation or updating, 138 
resident foreground programs, 63 
resident foreground programs, loading, 66 
resident foreground, scheduling tasks, 65 
resident section, 1 
restart, 4 

RESTORE control command, 94 
return registers, M:READ, 33 
return registers, MrWRITE, 39 
return status from M:IOEX, 30 
return status from MrREAD, MrWRITE, MrCTRL, 33 
REWIND control command (Monitor), 15 
REWIND control command (Utility), 102 
ROOT control command, 82 



routines, 27 

Abort, M: ABORT, 43 

Absolute Core Image Loader, M:LOAD, 46 

Allocate Temp Storage Without Transfer, M:RES, 52 

Assign RAD Files, M:ASSIGN, 50 

Character-Oriented Communication, M:COC, 55 

Checkpoint/Restart, MrCKREST, 45 

Close RAD File, M.-CLOSE, 47 

Convert OPLB to DFN, M:OPFILE, 53 

COPY, 102 

Date and Time-of-Day, M:DATIME, 42 

Diagnostic Without Writer, M:DOW, 54 

DUMP, 104 

Genera! Control, MrCTRL, 41 

General I/O Driver, MrlOEX, 27 

General Read, MrREAD, 31 

General Write, MrWRITE, 37 

Hex to Integer Conversion, MrHEXIN, 44 

Integer to Hex Conversion, MrlNHEX, 45 

Interrupt Restore, MrEXIT, 44 

Interrupt Save, MrSAVE, 44 

Load Overlay Segments, MrSEGLD, 48 

MrCOC Service, 165 

Normal Exit from Background, MrTERM, 43 

Object Module Editor, OMEDIT, 105 

Open RAD File, MrOPEN, 47 

RAD File Definition, MrDEFINE, 49 

Read Data Keys, MrDKEYS, 48 

Record Editor, RECEDIT, 107 

Reserve or Release Peripherals, MrRSVP, 53 

Sequence Editor, SEQEDIT, 109 

Simulated Wait Instruction, MrWAIT, 48 

Temp Storage Release, MrPOP, 53 
routines and idents for RBM part-2, 136 
routines, reentrant, 4 
routines, SYSGEN optional, 122 
RSKIP control command (Monitor), 13 
RSKIP control command (Utility), 102 



S (insert snapshot) Debug command, 142 

SAVE control command, 93 

scheduling resident foreground tasks, 65 

secondary storage management, 3 

SEG control command, 84 

semiresident foreground program, 63 

SEQUENCE control command, 111 

Sequence Editor control commands, 110 

Sequence Editor error messages, 116 

Sequence Editor operating characteristics, 109 

Sequence Editor operational labels, 109 

Sequence Editor routine, 109 

sequential files, 60 

sequential RAD files, special editing, 37 

sequential RAD files, write on, 40 
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service programs, 6 

service routines, 27 

solicited control, 23 

special editing for card reader, 36 

special editing for magnetic tape, 37 

special editing for paper tape or keyboard/printer, 36 

special editing for random-access RAD files, 37 

special editing for sequential RAD files, 37 

SQUEEZE control command, 94 

standard background operational labels, 10 

standard foreground operational lables, 11 

standard constants, 155 

standard device unit numbers, 12,60 

standard object language, 147 

status returns for M:COC, 56 

SU PRESS control command, 111 

SYSGEN and assembly time options, 167 

SYSGEN binary output, 133 

SYSGEN error messages, 134 

SYSGEN initial core allocation, 122 

SYSGEN input options and parameters, 128 

SYSGEN input parameters, 127 

SYSGEN operational label assignments, 127 

SYSGEN optional routines, 122 

SYSGEN output, 133 

SYSLOAD alarms, 139 

SYSLOAD UPD option (update), 135 

SYSLOAD, ALL option, 134 

SYSLOAD, RBM part-2, 136 

SYSLOAD, System Load, 133 

system communication, 20 

system environment, 1 

System Generation and System Load, 122-140 

system initialization and creation, 5 

system processor and library creation, 139 



T (selective dump) Debug command, 142 

task, 7 

Task Control Block (TCB) functions, 69 

task entrance format, 72 

TCB control command, 81 

TEMP control command (Monitor), 16 

temporary stack, 8 

three-character processor search, 167 

transfer vector for monitor services, 28 

TRUNCATE control command, 95 

U 

UNLOAD control command (Monitor), 16 
UNLOAD control command (Utility), 102 
unsolicited control, 23 
UTILITY control command, 100 
Utility Control commands, 101 

ASSIGN, 102 

CHANGE, 109 



Ut 
Ut 
Ut 
Ut 
Ut 
Ut 
Ut 
Ut 
ut 
Ut 
Ut 



COPY, 104 
DELETE, 107,108,110 
DUMP, 105 
END, 102 
FBACK, 101 
FSKIP, 101 
IDENT, 110 
INSERT, 107,109 
LIST, 107 
MESSAGE, 101 
MODIFY, 107,108 
OPLBS, 103 
PAUSE, 101 
PRESTORE, 102 
RBACK, 102 
REWIND, 102 
RSKIP, 102 
SEQUENCE, 111 
SUPPRESS, 111 
UNLOAD, 102 
UTILITY, 100 
UTILITY COPY, 103 
UTILITY DUMP, 105 
UTILITY OMEDIT, 106 
UTILITY RECEDIT, 108 
UTILITY SEQEDIT, 110 
VERIFY, 104 
WEOF, 102 

ty Control Function command error messages, 112 

ty Control Function processor, 99 

ty error messages, 1 1 1 

ty executive program, 99 

ty I/O error messages, 1 1 1 

ty operational labels, 100 

ty Operator Communication routine, 100 

ty program organization, 99 
I ity programs, 99-116 

ty source input interpreter, 99 
I ity subsystem, 6 



VERIFY control command, 104 



W 

WEOF control command (Monitor), 16 
WEOF control command (Utility), 102 



X (step snapshot) Debug command, 142 
XED control command (Monitor), 16 
XEQ control command (Monitor), 16 
XSYMBOL control command (Processor), 
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